1. final new static mock

    Jag måste säga det – Mockito smakar väldigt bra. Tidigare använde jag EasyMock och jMock och idag läste jag mig in på JMockit, som skriver:

    Design considerations for production code

    The problem with imposing restrictions on the design of production code is that there are good reasons for making classes final, for directly obtaining instances of collaborators with the new operator, and for using APIs based on static methods. There is nothing inherently wrong with using these three Java language keywords, after all.

    Fine. Jag kan köpa det. Men sedan går man vidare och säger

    The JMockit mocking API is simple, consistent, and minimal.

    Nu börjar det bli jobbigt att hålla med :) Låt oss ta deras exempelkod:

       public void testDoOperationAbc(final DependencyXyz mock)
       {
          new NonStrictExpectations()
          {
             AnotherDependency anotherMock;
    
             { anotherMock.doSomething("test"); result = 123; }
          };
    
          new ServiceAbc().doOperation("some data");
    
          new Verifications()
          {{
             mock.complexOperation(true, anyInt, null); times = 1;
          }};
       }

    och så jämför vi med samma sak i Mockito:

        public void testDoOperationAbc(final DependencyXYZ mock) {
            when(anotherMock.doSomething("test")).thenReturn(123);
            new ServiceAbc().doOperation("some data");
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    eller BDD-style:

        public void doOperationCallsComplexOperation(final DependencyXYZ mock) {
            // GIVEN
            given(anotherMock.doSomething("test")).willReturn(123);
    
            // WHEN
            new ServiceAbc().doOperation("some data");
    
            // THEN
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    I min värld är Mockito det mockningsramverk som är minst i vägen. För nyskriven kod vet jag vad mitt val faller på. Det är inte lika ”komplett” eller kraftfullt som andra ramverk, men så är det också inte i vägen. Måste man prompt använda final och static eller mocka privata metoder kan PowerMock hjälpa till.

  2. Bra verktyg för dåliga test?

    Jag sprang idag över denna demo av SpryTest – ett verktyg med vilket man kan få hjälp att skriva test som masserar legacy code (dvs kod som inte täcks av test). Nej, jag ser verkligen inte detta som en silver bullet och är tveksam till att använda det över huvud taget.

    (Läs mer…)

  3. När ska man mocka?

    Där jag jobbar nu mockar jag ungefär en gång i veckan. Nästa vecka kör vi vårens fjärde möte i JDojo@Gbg och temat för denna gång är just mockning. Vi kommer använda Mockito som jag tycker är mer lättanvänt verktyg än t ex EasyMock. En fråga som alltid dyker upp efter att man petat lite på ämnet brukar vara ”Vad är skillnaden mellan en stub och en mock?” I Mocks Aren’t Stubs har Fowler summerat det ganska bra tycker jag:

    • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
    • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
    • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
    • Mocks are [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

    Mockist Approach vs Stubborn Approach

    Detta är ett känsligt ämne – att påstå något om något som någon identifierar sitt arbete med. Jag brukar hävda att med stubborn approach (dvs när man bygger stubs eller fakes för sina collaborators/samarbetsklasser) så tenderar man att tappa fokus när man flyttar sin testverksamhet mellan olika klasser. Att använda en Mockist Approach (dvs när man mockar samarbetsklasserna runt sin ”enhet under test”) skulle på så sätt kunna hjälpa till att bibehålla fokus på den klass man utvecklar.

    Detta påstående brukar väcka lagom mycket anstöt för att få igång en givande konstruktiv diskussion där erfarenheter delas mellan debatörrer. Vad betyder det t ex när ett test med ett mockat beteende fallerar, jämfört med att använda en stub som kanske kan vara den verkliga (enda) implementationen?

  4. Delta i undersökning om effektivitet inom testning

    CITCON-listan är mottagare denna gång av en inbjudan från Tanjila Kanij vid Swinburne University of Technology, där man ber om deltagande genom en webbenkät som skall ta knappt 25 minuter att fylla i.

    ”[we are] conducting a survey to find out the key factors that influence the performance of software testers”

    Om du känner dig träffad (eller känner någon som borde känna sig träffad) så är URL:en till webbenkäten http://benambra.org/survey/

  5. Ny version av TextTest med utökad Java stöd

    TextTest är en verktyg för att stödja arbetssättet ”Text-based Testing”, som är en alternativ till klassiskt enhetstestning med t.ex. JUnit. Det nyligen kom en ny version av denna verktyg, 3.17, som har bättre stöd för Java än tidigare versioner. (Läs mer…)

  6. Apropå bananens böj

    Mistaeks I Hav Made skriver intressant om Make It Easy som jag ännu inte hunnit få användning för, men som ser ut att ha viss potential:

    To create a builder (or ”maker” in the framework’s lingo) that can be used multiple times:

    Maker<Banana> anIllegallyCurvedBananaWithinTheEU =
        a(Banana, with(curve, 45.0));
    Banana naughtyBanana = make(anIllegallyCurvedBananaWithinTheEU);

    To define makers in terms of other makers:

    Maker<Banana> aBananaThatCanBeUsedInTheManufactureOfSmoothies =
        anIllegallyCurvedBananaWithinTheEU.but(with(ripeness,1.0));
  7. Studie om testdriven utveckling

    Emellanåt ställs frågan om det påvisats att testdriven utveckling verkligen kan ge några konkreta, positiva resultat utanför skolprojekt, dvs i industrin. ”Ja, men det finns inte jättemånga som jag känner till”, är det svar jag brukar ge. IBM och Microsoft har publicerat en studie där man sett att TDD minskat antalet buggar med mellan 40 och 90 procent. De skriver:

    Test-driven development (TDD) is a software development practice that has been used sporadically for decades. [...] However, little empirical evidence supports or refutes the utility of this practice in an industrial context. Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.

    På tisdag kör vi igång en ny omgång av JDojo där vi genom övningar övar upp TDD-färdigheterna. Utöver JDojon  kommer vi också i vår genomföra motsvarande koncept ute hos kund i deras lokaler.

  8. XPDay London har startat

    Årets upplaga av XPDay har dragit igång och Gojko Adzic är inte sen att blogga om detta. Måste säga att det är intressant att Google byggt verktyg som utvärderar test, genom att titta på om ett fallerande test ledde till att kod ändrades eller lades till – vilket är bra – eller om testet i sig ändrades – vilket är dåligt (bl a pga underhållskostnader). Ca 100 miljoner dollar läggs årligen på automatisering av test och det finns potential att spara in 160 miljoner om buggar kan upptäckas tidigare i utvecklingscykeln, enligt Gojkos återrapportering.

    Konferensen hålls i två dagar där hela den andra dagens program utgörs av Open Space.

  9. Tack AJAX: Explosion av javascriptverktyg

    För några år sedan stötte jag ofta på ett förakt mot javascript. Kodare verkade hata detta och det var inte konstigt då många skrev kod i editorer utan något stöd och debugging skedde med alerts. Så kom ordet AJAX på allas läppar och helt plötsligt började verktygen förbättras och folks inställning blev mer positiv. Nu finns en hel uppsjö av riktigt bra verktyg både för att skriva kod, debugga och testa javascript. Webbutvecklaren Nathaniel T. Schutta har gjort en trevlig sammanställning, läs den.

  10. Continuous Integration-konferens startar i Paris

    Alldeles nu startar årets upplaga av Continuous Integration and Testing Conference Europe. Deras mailinglista har jag tipsat om tidigare och den har prenumeranter som är riktigt kompetenta får jag säga (annat är det med t e x JUnit-listan som bara handlar om ”what shoud I test – this is my class:”).

    För oss som inte har möjlighet att delta finns alltid twitter, även om det givetvis inte ger samma chans till delaktighet och erfarenhetsutbyte vid Open Space-sessionerna. Konferensen är för övrigt ”gratis” – dvs ingen avgift och ingen (Läs mer…)

  11. TDD inte utbredd i Java världen

    Det verkar som Java communityn inte har anamat Test Driven Development i så stor utsträckning. Kent Beck har nu lagt ner utveckling av JUnit Max på grund av den småa storleken på den potentiella marknaden. Han säger i sin blog:

    ”the data suggests that there are at most a few thousand Java programmers actively practicing TDD. That’s not a large enough market to sustain a business, especially as the market turned out to be price sensitive. Even if every Max subscriber successfully convinced 100 of their friends to sign up, there wouldn’t have been enough revenue.”

    Någon nämde i en kommentär till en föregående post om att det det kan finnas 6 miljoner Java programmerare, och det är enligt Tiobe världens populäraste programmeringspråk. Det gör mig så ledsen att höra att bara en liten liten bråkdel av oss använder TDD aktivt.

    Jag kan inte förändra hela världen, men jag kanske kan gör TDD lite vanligare bland Java utvecklare här i Göteborg. Kom och lär själv på JDojo@Gbg.

  12. TDD workshop at XP2009

    Martin and I were at XP2009 last week, and he has written a few posts about it already. I had a great time, there were lots of memorable moments. I particularly enjoyed a couple open space sessions sitting by the pool discussing geeky stuff while families splashed about and sunbathed nearby. I was actually a bit nervous about my session – how many people were going to come to it when it meant being indoors and sitting in a windowless room for 3 hours? Not to mention the fact I was competing with this fantastic tutorial with Joshua Kerievsky which Martin at least had decided was preferable… (Läs mer…)

  13. Jumblar du dina tester?

    Bra att du skriver tester, men hur bra är de egentligen?
    Med verktyg som muterar din kod (tex ändrar villkor i if-sats) och sedan kör testerna får du en bild av hur bra de fungerar. Det finns flera verktyg, ett av dem som funkar är Jumble som jag labbat lite med och det verkar bra. Men hur bra är de? Om du har erfarenhet av Jumble eller liknande verktyg (tex Jester, simple-jester, MuJava) lämna gärna en kommentar. Hur ofta används de? Kör ni dem i er byggprocess eller bara individuellt från er lokala miljö?

  14. Tillbaka till vaggan med Gradle?

    Jag är ett ”huge fan of Maven”. Jag skall dock villigt erkänna att jag suttit djupt ner i transitive dependencies-träsket och lite tyst svurit ”fy fan för Maven”. På e-postlistan för CITCON snackas det om många olika aspekter av byggande, testande, artifakthantering och sjösättning (deployment) och emellanåt dyker det upp tips om nya och gamla verktyg. Idag stötte jag på byggverktyget Gradle. (Läs mer…)

  15. Antipattern: Util-klasser

    Ta en titt i den kodbas du jobbar med. Hur många klasser har den som slutar på ”Util” eller liknande och som bara har statiska metoder? Om du inte hittar några så är det bara att gratulera, men troligtvis så hittar du en drös.

    Jag är innerligt trött på denna typ av utility-klasser, av två huvudsakliga skäl (som egentligen är två sidor av samma mynt):
    (Läs mer…)

Nästa sida