Hvad er Test-Driven Development (TDD)?

large__8282043567 testdrevet udvikling er en proces, der er afhængig af gentagelse af meget kort udviklingscyklus. Det er baseret på det første testkoncept ekstrem programmering, der tilskynder til simpelt design med høj grad af selvtillid.

proceduren for at gøre TDD følger:

  1. Skriv en test
  2. Kør alle tests
  3. skriv implementeringskoden
  4. Kør alle tests
  5. Refactor

denne procedure kaldes ofte rødgrøn-Refactor.

mens vi skriver tests, er vi i rød tilstand. Da testen er skrevet før den faktiske implementering, skal den mislykkes. Hvis det ikke gør det, er testen forkert. Det beskriver noget, der allerede eksisterer, eller det blev skrevet forkert. At være i grønt, mens du skriver test, er et tegn på falsk positiv. Sådanne Tests skal fjernes eller refactoreres.

næste kommer den grønne tilstand. Når implementeringen af den sidste test er afsluttet, skal alle test bestå. Hvis de ikke gør det, er implementeringen forkert og bør rettes.

ideen er ikke at gøre implementeringen endelig, men at give lige nok kode til, at testene kan bestå. Når alt er grønt, kan vi fortsætte med at refactor den eksisterende kode. Det betyder, at vi gør koden mere optimal uden at introducere nye funktioner. Mens refactoring er på plads, skal alle tests passere hele tiden. Hvis en af dem fejler, brød refactor en eksisterende funktionalitet. Refactoring bør ikke omfatte nye tests.

hastighed er nøglen

large_5836417589
jeg har tendens til at se TDD som et spil bordtennis (eller bordtennis). Spillet er meget hurtigt. Det samme gælder for TDD. Jeg har en tendens til ikke at bruge mere end et minut på hver side af bordet (test og implementering). Skriv en kort test og kør den (ping), skriv implementeringen og kør alle test (pong), skriv en anden test (ping), skriv implementering af denne test (pong), refactor og bekræft, at alle test passerer (score), gentag. Ping, pong, ping, pong, ping, pong, score, tjene igen. Forsøg ikke at lave den perfekte kode. Prøv i stedet at holde bolden rullende, indtil du tror, at tiden er inde til at score (refactor).

det handler ikke om test

T i TDD er ofte misforstået. TDD er den måde, vi nærmer os designet på. Det er måden at tvinge os til at tænke over implementeringen, før vi skriver koden. Det er den måde at bedre strukturere koden. Det betyder ikke, at test som følge af brug af TDD er ubrugelige. Langt fra det. De er meget nyttige og giver os mulighed for at udvikle sig med stor hastighed uden at være bange for, at noget vil blive brudt. Det gælder især, når refactoring finder sted. At være i stand til at omorganisere koden og samtidig have tillid til, at ingen funktionalitet er brudt, er et stort løft for kvaliteten af koden.

hovedformålet med TDD er kodedesign med test som et meget nyttigt sideprodukt.

Mocking

for at testene skal køre hurtigt og dermed give konstant feedback, skal koden organiseres på en måde, så metoder, funktioner og klasser let kan mockes og stubbes. Hastigheden af udførelsen vil blive hårdt ramt det, for eksempel, vores test har brug for at kommunikere med databasen. Ved at spotte eksterne afhængigheder er vi i stand til at øge denne hastighed drastisk. Udførelse af hele enhedstests suite skal måles i minutter, hvis ikke sekunder. Vigtigere end hastighed, at designe koden på en måde, så den let kan hånes og stubbes, tvinger os til bedre at strukturere denne kode ved at anvende adskillelse af bekymringer. Med eller uden mocks skal koden skrives på en måde, som vi for eksempel let kan erstatte en database med en anden. At” en anden ” kan være, for eksempel, hånet eller i hukommelsen database.

et eksempel på mocking i Scala kan findes i Scala Test-Driven Development (TDD): Unit Testing File Operations med Specs2 og Mockito artiklen. Hvis dit valgte programmeringssprog ikke er Scala, kan artiklen stadig være meget nyttig for at se det mønster, der kan anvendes på ethvert sprog.

overvågere

meget nyttigt værktøj, når du arbejder i TDD mode er overvågere. De er rammer eller værktøjer, der udføres, før vi begynder at arbejde og holder øje med enhver ændring i koden. Når en sådan ændring opdages, køres alle testene. I tilfælde af JavaScript tillader næsten alle byggesystemer og opgaveløbere dette. Gulp (min favorit) og Grunt er to ud af mange eksempler. Scala har sbt-revolver (blandt andre). De fleste andre programmeringssprog har lignende værktøjer, der kompilerer (hvis nødvendigt) og kører alle (eller berørte) tests, når koden ændres. Jeg ender altid med at have min skærm opdelt i to vinduer. Den ene med den kode, jeg arbejder på, og den anden med resultater af test, der udføres løbende. Alt hvad jeg skal gøre er at være opmærksom på, at output fra disse seere svarer til den fase, jeg er i (rød eller grøn).

dokumentation

en anden meget nyttig bivirkning af TDD (og velstrukturerede tests generelt) er dokumentation. I de fleste tilfælde er det meget lettere at finde ud af, hvad koden gør ved at se på test end selve implementeringen. Yderligere fordel, som andre typer dokumentation ikke kan give, er, at test aldrig er forældet. Hvis der er uoverensstemmelse mellem test og implementeringskoden, mislykkes test. Mislykkede tests betyder unøjagtig dokumentation.

test som dokumentationsartikel giver en lidt dybere begrundelse bag brugen af test i stedet for traditionel dokumentation.

Resume

efter min erfaring er TDD sandsynligvis det vigtigste værktøj, vi har i vores værktøjskasse. Det tager meget tid og tålmodighed at blive dygtig i TDD, men når den kunst er mestret, øges produktiviteten og kvaliteten drastisk. Den bedste måde at både lære og øve TDD på er i kombination med parprogrammering. Som i et spil bordtennis, der kræver to deltagere, kan TDD være parvis, hvor den ene koder skriver tests, og den anden skriver implementeringen af disse tests. Roller kan skifte efter hver test (som det ofte gøres i kodning dojos).

prøv det og giv ikke op, når du står over for forhindringer, da der vil være mange.

Test Driven Development( TDD): bedste praksis ved hjælp af Java-eksempler er et godt udgangspunkt. Selvom det bruger Java-eksempler, kan samme, hvis ikke alle, praksis anvendes på ethvert programmeringssprog. For et eksempel i Java (som i det foregående tilfælde er det let at anvende til andre sprog) bedes du tage et kig på TDD eksempel gennemgang artikel.

en anden god måde at perfektion TDD færdigheder er kode katas (der er mange på dette site).

hvad er din oplevelse med TDD? Der er lige så mange variationer, som der er hold, der praktiserer det, og jeg vil gerne høre om din oplevelse.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.