Tag: tdd

Agile Testing Days 2010 coming up

Speaker at Agile Testing Days 2010
I'll Be There

In about six weeks I’ll give a talk at Agile Testing Days together with Emily Bache. The talk’s title is set to “The Coding Dojo
as a forum for teaching TDD” and we are last to speak on Wednesday before the final key note of the day (and the “chill out” event). I’m looking forward to the conference which I’m sure will be full of insights and rewarding in many ways.

Bok: Test-Driven Development

Test-Driven Development By Example

av Kent Beck

ISBN: 9780321146533

Detta är en bok som i tre steg visar hur Kent Beck tycker man skall skriva kod. Boken är lättläst, enkel att förstå och Beck är ganska tydlig i vad  han menar och hur han föreslår att man skall jobba.

Min behållning av boken är den lilla privata lappen med “test att skriva” – något som han alltså förespråkar men som jag själv aldrig använt i större utsträckning. Jag petar istället ner alla test-idéer i kod, typ:

// FIXME: testa null

Om jag skall ge mig på att sammanfatta vad han förespråkar så är det:

  • börja litet
  • använd en lista där du skriver upp testfall som du vet eller kommer på behöver testas
  • låt design växa fram
  • använd refaktoreringssteget till att skriva den riktiga implementation
  • misslyckas man med ett stort test, skriv ett mindre istället
  • få hellre ett test till att gå igenom än att ha vacker kod

Jag rekomenderar boken till någon som har ett hum om vad TDD är men som inte sett hur det kan fungera i praktiken. Kodexemplen är visserligen ganska lätta men det intressanta är att se hur han jobbar med problemlösning, vad TDD-metodiken ger och att det banne mig inte är svårt att börja.

assertThat(Hamcrest).looksNice();

I väntan på David Saff’s alternative assertThat(x).y() så nöjer jag mig med:

public class EmptyMatcher extends TypeSafeMatcher<Collection < ?>> {

    @Override
    public boolean matchesSafely(Collection< ?> c) {
        return c.isEmpty();
    }

    public void describeTo(Description desc) {
        desc.appendText("empty");
    }

    @Factory
    public static lt;T> Matcher< ? super Collection> isEmpty() {
        return new EmptyMatcher();
    }
}

som gör att man kan skriva trevlig enkelt läsbar kod, t ex:

@Test
public void filteringAnEmptyListReturnsAnEmptyList() {
    List anEmptyList = new ArrayList();
    List result = testee.filter(emptyList());
    assertThat(result, isEmpty());
    // men helst: assertThat(result).isEmpty();
}

Eclipse och TDD

Eclipse är ganska svagt utrustat från start för att köra TDD effektivt. Det verkar inte komma ifrån att code completion måste utföras med CTRL+mellanslag – här kommer IntelliJ för alltid lysa med sin vackerhet (där mellanslag eller tab är “markören” som kollar om den skall auto-complete:a).

Favorites

Följande klasser är bra att peta in i varje workspace Window » Preferences » Java » Editor » Content Assistant » Favorites:

  • java.util.Arrays.*
  • java.util.Collections.*
  • org.junit.Assert.*
  • org.mockito.BDDMockito.*
  • org.mockito.Matchers.*
  • org.mockito.Mockito.*
  • org.mockito.MockitoAnnotations.*

Templates

Börja med att ta bort  alla SWT, ta bort test för JUnit 3.

WORK IN PROGRESS!

before

${staticImport:importStatic('org.mockito.MockitoAnnotations.initMocks')}
@${beforeAnnotation:newType(org.junit.Before)}
public void ${setup}() throws Exception {
  initMocks(this);
  testee = new ${cursor};
}

Det är givetvis trevligare med @RunWith(MockitoJUnitRunner.class). MoreUnit kan hjälpa till med att sätta upp detta.

mock

@Mock private ${type} ${mock};

bdd – BDD-ish Test

@Test public void statement() throws Exception {
    given(${mock}.${method}).willReturn(${value});

    // WHEN ${when}
    ${testee}.${act};

    // THEN ${then}
    verify(${mock}).${method}(${arguments});
}

tdd – TDD test

@Test public void statement() throws Exception {
    // Arrange
    // Act
    // Assert
}

JDojo – TDD i fem steg

Genom mitt jobb har jag haft det stora nöjet att få hålla ett antal kodningstillfällen som “lanserats” under namnet JDojo@Gbg. Det var tack vare Emily Bache som detta kom till stånd och när hon nu seglade vidare mot Ruby-landet så har jag tagit över vid rodret och det hela har, mer eller mindre, näst intill formaliserats i en serie beprövade övningar i olika ämnen (kurspaket om 10 timmar skulle säkert någon vilja kalla det).

Det som började med en ambition om att sprida TDD och andra goda principer för “hantverksyrket” programmering snappades ganska snabbt upp på olika arbetsplatser och till dags dato har snart fem olika grupper/JDojos genomförts (med fler i uppstartningsfasen) och detta är en liten sammanfattning (reflektion/retrospektiv) av hur det sett ut hittills.

Ämnen som avhandlats

Utan omsvep så har vi under dessa JDojos avhandlat följande ämnen, med – för alla deltagare – mycket givande diskussioner.

Testdriven utveckling

Ett ämne som försvaras ganska brett (värdet av en bra testsvit) men “lärs ut” ganska smalt. Under SDC2010 i en fishbowl-debatt på temat “Should every proffessional developer practice TDD” var de flesta överens om “nja, det viktiga är en bra testsvit, men hur man kommer fram till den är inte givet” medan Michael Feathers mer var av åsikten “outside of Sweden, this is more or less concidered the solution”.

The Solution, med “test first”, red-green-refactor, etc lärs ut eller gås igenom i denna första övning.

Clean Code

Efter en introduktion till TDD och själva processen tar vi upp saker som “test backlog” och fokuserar ännu mer på refactor-steget och diskuterar (och deltagarna på något sätt enas om) definitionen av Clean Code. Ett antal best practices tas fram och även om det låter som ett tunt ämne så är diskussionerna här alltid rika, nyanserade och har beskrivits som “mycket värdefulla”.

Objektorienterad utveckling och TDD

Nästa steg i utforskandet av TDD har varit att titta på vad som händer när man tar steget från “enklare” imperativ/funktionell programmering och in i det objektorienterade landskapet. Med rätt uppgift och lagom dos moderering tyder ett mönster fram som i princip går ut på mycket fokusskifte mellan klasser. Ganska snart i retrospektiven brukar ett samtal kring kring inside-out, bottom-up och top-down dyka upp.

Mockist vs Stubborn Approach

Efter att ha känt på det dyra med att skifta fokus fram och tillbaka med TDD och OO bjuder nästa övningstillfälle på möjligheten att med hjälp av mockning (Mockito) bibehålla fokus på “en klass i taget” och i större utsträckning kunna fokusera på interaktionen, gränssnitt och enskilda klassers roller. Syftet med mockning, och när det är lämpligt att mocka, blir tydligt i jämförelse med föregående övning.

Behaviour Driven Development

Den femte övningen har antingen fokuserats mot BDD om det funnits intresse för detta. Fokus har legat på formen av GIVEN, WHEN, THEN och det somliga kallar ryska dockor och andra utifrån-in eller outside-in.

Legacy Code / befintlig kod

Ett annat efterfrågat ämne är hur man inför TDD-tänk kring kod som inte redan täcks av test, eller kanske inte är testbar (eller iaf svårtestad). Michael Feathers bok “Working Effectively with Legacy Code” demonstrerar detta på ett utomordentligt bra sätt och i denna övning har vi tagit kundens befintliga kodbas (om möjligt/lämpligt) och bearbetat den för att uppnå olika mål.

Mer (än) rubriker

Givetvis avhandlas många olika aspekter av systemutveckling parallellt, t ex Characteristics of a Good Test, Enough Tests? 3A vs BDD? Baby Steps, TDD vs Traditional Testing, …

Workshop i Eclipse som mjukstart

Vid ett par tillfällen har vi inlett med en workshop om effektiv utveckling i Eclipse. Detta har gett utvecklarna en möjlighet att känna på Dojo-ledaren, och omvänt en möjlighet att anpassa materialet efter gruppens förkunskaper och önskemål.

Formen för övningstillfällena

Vi har i huvudsak använt Eclipse, JUnit, Mockito och FitNesse. De 120 minutrarna används effektivt med en introduktion av dagens övning och ibland av det ämne man skall behandla – värdet av självinsikt får vägas in här och anpassas efter gruppen. Ca 90 minuter används till utförandet av övningen och avslutas med en en lagom kort retrospektiv där övning, erfarenheter och reflektioner tas upp och blandas friskt.

Vad är en Coding Dojo?

Dojo är namnet på lokalen där bl a olika kampsporter utövas, t ex Karate. 2005 lanserades termen “Coding Dojo” (eller Coders’ Dojo) där principen är att man upprepat utför vissa övningar, så att man genom repetition övar upp olika färdigheter/kunskaper så att när man behöver dem i “skarpt läge” kan man med lätthet kan agera på ett korrekt och säkert sätt.

Ingen föresläsningsserie – aktivt deltagande ger verkliga erfarenheter

Den Java-Dojo som Iptor nu bedrivit har visserligen fått en uppsättning övningar som vi fått efterfrågan på, och därför kunnat upprepa med mycket liknande resultat. Det är dock inget föreläsningspaket som deltagarna kan sova sig igenom – tvärtom skall varje individ sitta i “the hot spot” och parpogrammera. Praktisk erfarenhet och kunskap är mål utöver teoretisk kännedom och bekantskap.

Material

Skall försöka peta ut allt material här. Ikväller blir än så länge bara följande:
JDojo1: TDD och
Kata String Calculator