Testdriven utveckling - Min historia

Varför det är bra med testdriven utveckling kan du läsa på många ställen. Du kanske tänker att det inte kommer att funka i just ditt system, just nu, eller just den här kunden. Så är det nog inte. Det handlar nämligen om dig.

Jag har utvecklat programvara i snart 30 år. Jag började som så många andra i min generation att skriva Basic på en Vic64, sekventiell kod, program som inte gjorde någonting vettigt alls utan bara var roliga att skriva. Med åren blev de mer och mer på riktigt, och de senaste 15 åren har det varit mitt yrke att utveckla programvara.

I rätt många år har jag hört om allt bra med testdriven utveckling. Det finns tusen bra argument. Alla håller med. Ingen säger emot – men det är ytterst få som faktiskt gör det. Så hur vet vi att det är bra? Jo, de som faktiskt gör det kan visa det ganska enkelt. Så varför gör ingen det? För att det är svårt att komma igång. Det finns trösklar, men det är inte de trösklar som folk pratar om som är problemet.

För några år sedan försökte jag, och de omkring mig i projektet ute hos kunden, arbeta testdrivet. Vi skrev enhetstester för ”allt” och det var vansinnigt mycket arbete. Det blev onödigt dyrt, testerna blev svåra att underhålla, och det tog tid och det löste egentligen inget, för vi hittade ju inga fel och... Där kom de. Några av de vanliga invändningarna. Det var ett nytt system, med en mycket genomtänkt och elegant arkitektur. Vi slapp alltså alla de problem man måste övervinna om man ska införa testdrivet i efterhand i form av att bryta alla hårda kopplingar som finns i traditionella system och på allehanda sätt göra koden testbar, men ändå var det svårt. Varför var det det? Var det ett svårtestat system? Var det en komplicerad arkitektur som gjorde det svårt? Var det svåra affärsregler? Nej, det var det inte. Det var något annat.

Vad är problemet?

Nu när jag tänker tillbaka, var det nog som huvudpersonen säger i slutet av filmen Platoon: "I think now, looking back, we did not fight the enemy; we fought ourselves. And the enemy was in us.” Det var svårt för att vi inte kunde. Vi visste inte på vilken nivå vi skulle testa, vad vi skulle testa, vilka verktyg som var lämpliga, hur de skulle tillämpas eller ens egentligen varför vi skulle göra det. Men det allra svåraste var sättet att tänka.

Om man i väldigt många år arbetat på ett visst sätt, där man tänkt i termer av vilken kod som ska skrivas, och inte i termer av vilket problem som ska lösas, så är det svårt att ändra sig. Att börja att skriva sitt krav i en exekverbar form och inte i Word, att i en första version skriva ”verksamhetskod” som inte gör någonting utom att returnera Sant så att testet går igenom, det är svårt. Det är att vända ut och in på huvudet. Det är nog faktiskt det som varit svårast av allt i att lämna den Mörka Sidan.

Top tre saker att övervinna

1. Våga lita på att den testdrivna processen går fortare och säkrare, än att "bara skriva koden"
2. Faktiskt tänka "Krav först", istället för "Implementation först", och låta implementationen växa fram ur kraven
3. Att arbeta i tillräckligt små cykler av krav/test/kod. Små, små ändringar, och sedan köra tills det blir grönt

Det är så lätt att halka tillbaka i sitt gamla tänk, och ”bara” fixa den där buggen, att låta sig stressas till att tro att det går fortare att skriva koden direkt än att skriva kraven först, trots att vi alla någonstans egentligen enats om att det inte är så, för det är inte så det känns. Det är intuitivt fel för den ovane. Det är så svårt att inte fastna i föreställningen av hur mycket man måste göra för att det ska gå att skriva ett enda litet test. Det är så svårt att se att allt arbete för att skriva det första lilla kravet, som säger att Hello World ska skrivas ut i Välkomstmeddelandet, att det arbetet faktiskt är något du har gratis till nästa test. Och ännu mer gratis till nästa. Igår skrev jag ett helt nytt exekverbart krav utan att behöva skriva en enda rad testkod, utöver själva kravet. Allt fanns redan. Men det var en bit dit.

Hur löser man det?

Men vad gör man då? Hur vänder man sin tanke ut och in?

Skaffa en personlig tränare. Du kan inte själv. Du kan inte köpa ett gymkort och bara kliva in och börja rycka och slita i hantlar och skivstänger om du aldrig gjort det innan. Du gör dig illa. Det hjälper inte heller att se en Youtube-video med någon som kan och säger att det är lätt. Det är det faktiskt inte. Du behöver instruktioner, och du behöver någon som går bredvid dig ett tag och hjälper dig när du börjar slarva med rörelserna. Du behöver någon att bolla med, någon som kan, som gjort det förr.

Inte förrän jag fick börja göra detta tillsammans med min Agero-kollega, som kan och som gjort detta i flera år förstod jag. Han kunde visa de subtila skillnaderna i hur man formulerar sina krav i produkten SpecFlow, och hur man organiserar sin testrigg på ett smart sätt. Det är egentligen ganska små, subtila, saker, men de är filosofiskt viktiga, och de gör väldigt stor skillnad i hur mycket de kan återanvändas. Han kunde visa hur du ser till att du slipper skriva om allt för att en detalj ändrar sig. Det är de skillnaderna, de insikterna, och de tankarna som är skillnaden mellan en testrigg som ger mycket tillbaka och en som mest är i vägen och kostar pengar.

Slutsats

Det går att lära om, och att lära sig att göra rätt. Aha-upplevelsen och tillfredsställelsen när man plötsligt förstår hur mycket högre kvalitet man levererar är enastående. Det är inte tekniken som är problemet. Problemet ligger i ditt sätt att tänka.

Börja NU, men ta hjälp! Prova tillsammans med någon som kan.

Läs gärna vidare i samma tema om hur Specification by example och konkreta exempel kan hjälpa dig i ditt nästa IT-projekt.