Varför enhetstesta – anledning 1

Inlägg i denna serie, ”Anledningar att enhetstesta”:

Anledning 1 – Dokumentationseffekten

Anledning 2 – Säkerhetsbälteseffekten

Anledning 3 – Designeffekten

---

Jag tänkte köra en serie inlägg med fokus på anledningar till att enhetstesta. Jag kommer att köra dem utan inbördes ordning – alltså utan någon sorts prioritering dem emellan. Delvis för att jag inte är 100% säker på vilket argument som är det viktigaste. Det finns, som jag upplever det, många anledningar! Gissar på ett inlägg i veckan, vi får se hur snabbt det går.

Så här kommer en anledningen idag; det blir den dokumenterande effekt enhetstester har.

Om man jobbar på ett projekt tillsammans med några kollegor, eller för den delen tittar på sin egen kod från några månader sedan, händer det att man tar sig för pannan och undrar ”Hur fungerar nu den här klassen/funktionen igen?”. Exempelvis kan jag ställa mig frågor i stil med dessa:

• ”Kan jag skicka in null för parametern secondaryPoly eller klarar inte funktionen av det? Måste jag skapa en tom poly då i min situation?”
• ”Är det meningen att jag ska lägga till alla A-punkter först och sedan alla B-punkter i gridden? Kan jag blanda?”
• ”Kan jag använda Compute() och sedan lägga till några A:n, för att sedan kunna använda Compute() igen?”
• ”Kommer metoden att krascha om jag skickar in ett negativt tal, eller bara returnera 0?”

Den typen av frågor – om hur det är tänkt att en funktion eller ett objekt ska fungera – tillhör egentligen dess dokumentation. Men som van programmerare vet jag väldigt väl hur sällan dokumentation kommer på plats – och hur lite jag litar på dokumentation som finns (den blir så snabbt gammal pga ändringar i kodbasen!). Ofta är inte heller dokumentationen heltäckande (så kallade edge cases beskrivs inte, utan bara huvudfunktionen).

Utan enhetstester, finns det två vägar – störa sin kollega (om det inte är min egen kod!) – eller läsa igenom hur koden fungerar genom att titta under huven – läsa källkoden direkt. Och om man frågar en kollega är det inte alltid man får 100% pålitliga svar – de har inte allt i huvudet, lika lite som jag.

Med enhetstester finns det en tredje väg. Du kan kolla direkt på hur koden är tänkt att fungera genom att läsa igenom enhetstesterna!

För att få lite smak för detta argument, jämför hur du förstår klassen ”Countdown” genom att både läsa dess kod och dess enhetstester. Observera att detta är en väldigt liten klass – och med en större klass blir den dokumenterande effekten än viktigare såklart!

Countdown.cs (klasskod)

CountdownFixture.cs (enhetstester)

Taggar: programmering, tdd, enhetstester, enhetstestning, dokumentation

Annons