14:28:48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction – 99 is not a valid value
java.lang.Exception: 99 is invalid
at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na]
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9]
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9]
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12]
at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na]
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12]
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12]
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12]
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]

Tack för din kommentar!

Jag svarar på dina punkter i samma form för enkelhets skull.

1) Länken är fixad – tack! :-)

2) Felmeddelanden spelar in, men känns inte som något avgörande. Alla ramverken ger dig den information som du behöver, så det handlar bara om att lära sig läsa den (och det behöver du med alla). I vissa fall tycker jag att EasyMock ger tydligare information än Mockito, så det beror nog på situationen.

När det gäller mina kodexempel så går jag inte in något direkt på olika assertions, så att jag valt att använda javas inbyggda assert är bara för att göra exemplen tydliga. EasyMock går ju också att använda med Hamcrest, så det ser jag inte som ett stort problem.

3) Jag tror nog att de flesta (om inte alla) använder static imports för EasyMock och Mockito, men jag har valt att inte göra det i kodexemplen för att göra det tydligare var metoderna som används är deklarerade (det skulle ju kunna vara något egenhackat annars). Av exemplen går det ju att se att det är statiska metoder som anropas och då kan du välja hur du vill hantera det i din egen kod.

Även i praktikten tycker jag faktiskt att det är ganska liten skillnad på ramverken, jag har använt alla tre och tycker att de ger olika bra felmeddelanden i olika lägen. Tröskeln är nog att lära sig mocktestning som koncept, snarare än det specifika API:t.

1) Länken i slutet av blogginlägget verkar inte vara avslutat – klickar man i formuläret här så kommer man till mockobjects.com :)

2) Jag skulle säga att du inte tagit upp en minst lika viktig aspekt, nämligen felmeddelandena man får när något inte blir som tänkt – antingen det är felprogrammerat eller om koden under test beter sig annorlunda än avsett. Där tycker jag det är mycket stor skillnad mellan t ex EasyMock och Mockito. Det kan göra stor skillnad vid felsökning.

En liknande skillnad i just tydlighet i felmeddelande är möjligen att använda Hamcrest:
assertThat(actualPacket, isEqualTo(expectedPacket));
istället för
assert expectedPacket == actualPacket;
men det tycker jag är än mer en smaksak.

3) En annan ny feature i Java 5 är ju static imports vilket jag tycker gör kodan ovan mycket mer läslig (dvs ta bort ”Mockito.” och ”EasyMock”, något man inte kommer från med mockery-objektet).

Rent funktionellt så håller jag helt med – det är mycket liten skillnad. I praktiken drar jag inte samma slutsats utan rekomenderar Mockito eftersom tröskeln har varit lägre, dokumentationen enklare och felmeddelanden mycket tydligare och förklarande.