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. 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.

  3. 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.

  4. 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…)

  5. 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ö?

  6. 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…)

  7. Bättre hjälp för import static i Eclipse

    Sitter just nu med att bryta isär enhetstest och integrations test i ett projekt, samtidigt som jag skall öka testtäckningsgraden. Bland det jag stöter på märker jag att Eclipse har rätt kass stöd för att föreslå automatisk statisk import av metoder, såsom Assert.assertEquals och EasyMock.expect.

    En workaround är att lägga till just dessa vanliga klasser som ”favoriter”. Öppna Window > Preferences, och lägga till varje klass mha ”New Type” under Java > Editor > Content Assist > Favorites. Voila! Nu är det bara att skriva assert<ctrl+space> och man får det som man vill.

    Förhoppningsvis blir detta bättre i Eclipse med tiden – denna workaround gäller för 3.4.

  8. Programmet klart

    Nu är programmet klart till Scandinavian Developer Conference. Det är blir 6 parallella sessioner med många tunga talare. Keynote speaker är ingen mindre än Kent Beck, upphovsmannen till XP och en av grundarna till hela den agila rörelsen. Förutom konferensen kommer hela veckan fyllas med evenemang (bla certifieringskurs i Scrum) under Open Event men detta är inte klart ännu. Du kan själv vara med att arrangera Open Event!

    Kolla in konferensen på www.scandevconf.se

  9. Junit + EasyMock

    Hittade en välskriven engelsk guide om hur man arbetar med jUnit och EasyMock. Kan rekommendera den till er som inte tidigare jobbat med EasyMock tillsammans med jUnit.

    EasyMock + jUnit guide