Vad är testdriven utveckling (TDD)?

large__8282043567testdriven utveckling är en process som bygger på upprepning av mycket kort utvecklingscykel. Den är baserad på Test-första begreppet Extreme Programming (XP) som uppmuntrar enkel design med hög grad av förtroende.

proceduren för att göra TDD följer:

  1. Skriv ett test
  2. kör alla tester
  3. skriv implementeringskoden
  4. kör alla tester
  5. Refactor

denna procedur kallas ofta rödgrön-Refactor.

när vi skriver tester är vi i rött tillstånd. Eftersom testet är skrivet före det faktiska genomförandet, är det tänkt att misslyckas. Om det inte gör det är testet fel. Det beskriver något som redan finns eller det skrevs felaktigt. Att vara i grönt medan du skriver tester är ett tecken på falskt positivt. Sådana tester bör tas bort eller refactored.

nästa kommer det gröna tillståndet. När genomförandet av det sista testet är klart ska alla tester passera. Om de inte gör det är genomförandet fel och bör korrigeras.

tanken är inte att göra implementeringen slutgiltig, utan att ge tillräckligt med kod för att tester ska passera. När allt är grönt kan vi fortsätta att refactor den befintliga koden. Det innebär att vi gör koden mer optimal utan att införa nya funktioner. Medan refactoring är på plats, bör alla tester passera hela tiden. Om en av dem misslyckas bröt refactor en befintlig funktionalitet. Refactoring bör inte innehålla nya tester.

hastighet är nyckeln

large_5836417589
jag brukar se TDD som en omgång ping pong (eller bordtennis). Spelet är väldigt snabbt. Samma sak gäller för TDD. Jag brukar inte spendera mer än en minut på vardera sidan av bordet (test och implementering). Skriv ett kort test och kör det (ping), skriv implementeringen och kör alla tester (pong), skriv ett annat test (ping), skriv implementering av det testet (pong), refactor och bekräfta att alla tester passerar (poäng), upprepa. Ping, pong, ping, pong, ping, pong, poäng, servera igen. Försök inte göra den perfekta koden. Försök istället att hålla bollen i rullning tills du tror att tiden är rätt att göra mål (refactor).

det handlar inte om att testa

T i TDD missförstås ofta. TDD är hur vi närmar oss designen. Det är sättet att tvinga oss att tänka på implementeringen innan vi skriver koden. Det är sättet att bättre strukturera koden. Det betyder inte att tester som härrör från att använda TDD är värdelösa. Långt ifrån det. De är mycket användbara och tillåter oss att utvecklas med stor hastighet utan att vara rädda för att något kommer att brytas. Det gäller särskilt när refactoring äger rum. Att kunna omorganisera koden samtidigt som man har förtroende för att ingen funktionalitet bryts är ett enormt lyft för kodens kvalitet.

huvudsyftet med TDD är koddesign med tester som en mycket användbar sidoprodukt.

Mocking

för att tester ska kunna köras snabbt och därmed ge konstant återkoppling måste kod organiseras på ett sätt som metoder, funktioner och klasser lätt kan hånas och stubbas. Hastigheten på utförandet kommer att påverkas allvarligt det, till exempel, våra tester måste kommunicera med databasen. Genom att håna externa beroenden kan vi öka den hastigheten drastiskt. Hela enhetstester suite utförande bör mätas i minuter om inte sekunder. Ännu viktigare än hastighet, utforma koden på ett sätt som det lätt kan hånas och stubbed tvingar oss att bättre strukturera den koden genom att tillämpa separation av oro. Med eller utan hånar ska koden skrivas på ett sätt som vi till exempel enkelt kan ersätta en databas för en annan. Att ”en annan” kan vara, till exempel, hånade eller i minnet databas.

ett exempel på hån i Scala finns i Scala Test-Driven Development (TDD): Enhetstestfiloperationer med Specs2 och Mockito-artikeln. Om ditt programmeringsspråk inte är Scala kan artikeln fortfarande vara mycket användbar för att se mönstret som kan tillämpas på vilket språk som helst.

Watchers

mycket användbart verktyg när du arbetar i TDD mode är watchers. De är ramar eller verktyg som körs innan vi börjar arbeta och tittar på eventuella ändringar i koden. När en sådan förändring upptäcks körs alla tester. Vid JavaScript tillåter nästan alla byggsystem och uppgiftslöpare detta. Gulp (min favorit) och Grunt är två av många exempel. Scala har sbt-revolver (bland andra). De flesta andra programmeringsspråk har liknande verktyg som kompilerar om (om det behövs) och kör alla (eller påverkade) tester när koden ändras. Jag slutar alltid med att min skärm delas upp i två fönster. En med koden jag jobbar med och den andra med resultat av tester som körs kontinuerligt. Allt jag behöver göra är att uppmärksamma att utsignalen från dessa tittare motsvarar den fas jag är i (röd eller grön).

dokumentation

en annan mycket användbar bieffekt av TDD (och välstrukturerade tester i allmänhet) är dokumentation. I de flesta fall är det mycket lättare att ta reda på vad koden gör genom att titta på tester än själva implementeringen. Ytterligare fördel som andra typer av dokumentation inte kan ge är att tester aldrig är föråldrade. Om det finns någon skillnad mellan tester och implementeringskoden misslyckas testerna. Misslyckade tester innebär felaktig dokumentation.

tester som dokumentation artikeln ger lite djupare resonemang bakom användningen av tester i stället för traditionell dokumentation.

sammanfattning

enligt min erfarenhet är TDD förmodligen det viktigaste verktyget vi har i vår mjukvaruverktygslåda. Det tar mycket tid och tålamod att bli skicklig i TDD men när den konsten behärskas ökar produktiviteten och kvaliteten drastiskt. Det bästa sättet att både lära sig och öva TDD är i kombination med parprogrammering. Som i ett spel med ping pong som kräver två deltagare kan TDD vara i par där en kodare skriver tester och den andra skriver genomförandet av dessa tester. Roller kan växla efter varje test (som det ofta görs i kodning dojos).

ge det ett försök och ge inte upp när du står inför hinder eftersom det kommer att finnas många.

testdriven utveckling (TDD): bästa praxis med Java-exempel är en bra utgångspunkt. Även om det använder Java-exempel kan samma, om inte alla, metoder tillämpas på alla programmeringsspråk. För ett exempel i Java (som i föregående fall, det är lätt aplicable till andra språk) ta en titt på TDD exempel genomgång artikeln.

ett annat bra sätt att perfektion TDD färdigheter är kod katas (det finns många på denna webbplats).

Vad är din erfarenhet av TDD? Det finns lika många variationer som det finns lag som övar det och jag skulle vilja höra om din upplevelse.

Lämna ett svar

Din e-postadress kommer inte publiceras.