TDD

Hvad er test-driven development? Jeg har læst og hørt flere forklaringer, heriblandt de nedenstående:

  • “Test-driven development er en avanceret brug at automatiserede unit tests, der skal drive designet af din software og gennemtvinge lav kobling. Resultatet af denne praksis er en omfattende samling af unit tests, der kan køres når som helst du ønsker en tilbagemelding på, om applikationen stadig virker efter hensigten.”

  • “Tænk på test-driven development som en måde, hvorpå du kan forvandle din kode til en instruktionsmanual for sig selv. Ved at skrive testene først laver du et detaljeret roadmap for, hvordan din applikation skal se ud for at leve op til kravene. Du lader dine tests fortælle dig, hvad det næste skridt er.”

I praksis foregår TDD som illustreret på nedenstående tegning:


Og hvis du ligesom mig har brug for en mere uddybende guideline til TDD i praksis, så kommer den her:
  1. Du opretter klassen (hvis den ikke allerede eksisterer) og tilføjer din nye metode til klassen med metodenavn, evt. parametre og en return type. Metodens krop lader du være tom, medmindre du har en return type. I det tilfælde skriver du en enkelt linje til at returnere null, -1, false eller hvad en fejlet værdi nu ellers ville komme til udtryk som. Du kan selvfølgelig også lade være med at skrive noget som helst, men så vil du få kompileringsfejl, når du prøver at debugge dine tests, og det er ikke disse fejl, som vi er interesserede i at få. 

  2. Du skriver de tests, som du mener er nødvendige for at verificere, at funktionaliteten i din metode lever op til kravspecifikationen. 

  3. Kør dine tests og se dem fejle.

  4. Skriv den kode, der er nødvendig for at testene består. Hold det enkelt og lad være med at tænke for meget over design og god kode skik (og ja, det sagde jeg lige!).

  5. Kør dine tests og se dem bestå.

  6. Refactor din kode og verificer, at den stadig lever op til kravene ved at køre dine tests.

  7. Gå videre til den næste metode/funktionalitet.

Note; du behøver ikke at begrænse din implementering til den ene metode. Hvis det giver mere mening at opdele den i flere metoder, der alle indgår i den første metodes flow, så er du mere end velkommen til at gøre det. Dine unit tests kigger på resultatet, ikke på hvordan du kom frem til det. 

Du opnår hermed flere fordele med dine tests:

  • Du tænker over, hvad din kode skal bruges til, før du begynder at implementere kravspecifikationen. Ikke nok med at du tester for fejl, du forebygger dem også.

  • Dine tests bliver ikke en træls opgave, der skal udføres efter du selv føler, at du har løst opgaven. De bliver den rettesnor, der fortæller dig, hvornår du er færdig med opgaven, og hver eneste grønne lampe bliver et win undervejs i implementeringen.

  • Bagefter har du en samling unit tests, som både du og andre til enhver tid kan køre for at verificere, at koden stadig overholder kravspecifikationen.

  • Sidst, men absolut ikke mindst, refactoring indgår som en naturlig del af din udvikling.

Fortsættes...

Del 7: TDD

Ingen kommentarer:

Send en kommentar