Vad är TDD?
Testdriven utveckling fokuserar som metod på att skriva tester först och kod därefter. Testerna skrivs för att verifiera och validera kod innan själva koden skrivs. Genom att ha en uppsättning tester som körs automatiskt varje gång koden ändras, kan utvecklare vara säkra på att inga buggar har introducerats i koden. Personligen använder jag framför allt TDD för enhetstester, men man kan såklart använda tankesättet för till exempel funktionstester eller acceptanstester.
Några fördelar med testdriven utveckling
Kom i gång lättare
Största styrkan med TDD är det alla utvecklare står inför. Du har ett problem, du öppnar din editor, du tittar på den blanka ytan och vet inte riktigt hur du ska börja. Om man skriver ett test, vad som helst, så kommer tankeverksamheten i gång. Vad ska jag använda det till? Hur kommer jag att använda det? Kommer någon annan att använda det?
Man tar ett steg i taget genom att skriva ett test, och får testet att gå igenom. Ett test som jag brukar skriva, som jag får skäll av kollegorna för, är ett test för en konstruktor. Det kanske inte ger så mycket – men ger mig definitivt chansen att komma i gång.
Testtäckning skapar självförtroende
Testtäckning är ett mått på hur mycket av eventuella kod-paths som är täckta av test. Har man en hög grad testtäckning så vet jag att ingenting kommer att gå sönder på vägen om jag till exempel ändrar något i modul A, som i många steg är länkat till modul Z.
Däremot anser jag att det är ouppnåeligt att ha 100 procents testtäckningsgrad. I stället bör testtäckningen fokusera på att täcka de viktigaste och mest kritiska delarna av koden och de funktioner som förväntas fungera korrekt.
Fungerar som dokumentation och leder till läsbar kod
Om man skrivit bra tester och har tillräckligt hög täckningsgrad räcker dessutom detta som dokumentation, för utvecklare, för hur ett API ska användas. TDD leder till mer läsbar kod. Läsbarhet är väldigt viktigt. Testernas metodsignaturer kan även struktureras efter kontext – jag gillar att använda mig av ”given-when-then”.
Så kan du ta dig an TDD-metoden i ett projekt
Är du helt grön så kan testdriven utveckling var svårt och märkligt. Det är väldigt lätt att skriva test som inte ger någonting. Ta därför gärna hjälp av någon i din närhet för att parprogrammera. Annars finns skrivna tester på Github som skapar en känsla av hur ett test kan skrivas.
Flödet i ett test är arrage, act, assert. Man arrangerar upp det förväntade värdet och de ingångsparametrarna som behövs för att göra själva testet. Sen gör man testet. För att sedan kolla att det blev så som man trodde att det skulle bli. Testkod är precis som all annan kod – den ska vara enkel och precis.
Sen gäller det att bena ut vilka tester som ger värde och som man ska ha kvar. Boken Clean Code är en bra språngbräda för dig som är ny till testdriven utveckling – i den pratas det mycket test.
Kan testdriven utveckling leda till att man skriver mer och mer komplicerad kod?
Ja, det kan hända att man börjar lägga ner mycket tid på det runt omkring, byggandet. För att undvika detta kan man börja med ett ”clean sleght”. Kommer man in i ett projekt som redan har kod kan man behöva bygga upp ett ”test harness” – för att man ens ska kunna börja testa på ett bra sätt. Man får ”massera” in koden så att den blir testbar.
Tips på frameworks för TDD
Vad gäller verktyg så spelar de mindre roll, bara man har inställningen att man gör tester. Just nu föredrar jag xUnit för .net-utveckling. Tidigare har jag använt mig av NUnit. Sen finns det massa hjälpmedel, till exempel Fluent Assertions som nästan blir som prosa. Eller Fake It Easy som fyller funktionen att man skriver sitt API baserat på interface. Med hjälp av verktyg som Fake It Easy kan man ta ett interface och säga ’jag ska sätta upp det så att när jag kallar på den här metoden, så ska du returnera det här värdet’.
Här finns det dock ett litet kaninhål som man kan hamna i, jag har hamnat där några gånger. Det är att när man börjar skriva testet, så börjar man testa sitt mockobjekt eller det som egentligen är den falska biten. Det kan vara en konsekvens av att man tar fel väg in.
Lär dig mer om TDD
I avsnitt 42 av Consids podd Utveckla snackar jag, Kristofer Linnestjerna, testdriven utveckling med poddhosten Lily och Simon. Lyssna på poddavsnittet för att lära dig mer om TDD.
