Tillhör du de som tycker att vi som jobbar med programmering alltid ligger i utvecklingens framkant och är först med det senaste, medan andra yrkeskategorier mest är mossiga och hopplöst nittonhundrataliga? Sorry, i så fall måste jag rubba din världsbild. På åtminstone ett område ligger vi ett halvt millenium efter ekonomerna.
Tanken slog mig när jag lyssnade på Jeffrey Fredricks seminarium Continuous Integration, Continuous Agitation häromdagen och Jeff berättade att hans erfarenhet var att man måste skriva åtminstone lika mycket testkod som programkod för att få 70 % testtäckning. Dubbelt så mycket kod!? Är inte det slöseri och något som den första Lean-principen säger åt oss att eliminera? Kanske inte. Plötsligt lämnade jag Norra Latin och föll genom ett hål i rum-tidväven tillbaka till fjortonhundratalets Italien där jag blev vittne till hur matematikern och munken Luca Pacioli fann sin gode vän, handelsmannen signor Bocelli, djupt deprimerad:
– Ah, Broder Luca, du kanske kan hjälpa mig. Jag blir tokig på min odåga till figlio. Som du vet tog han över la compagnia för två år sedan.
– E? Vad har hänt? Jag trodde att affärerna gick eccelente.
– Ja, sälja kan han, men han kan inte addera ett och tre utan att få det till cinque. Igår hittade jag av en slump flera slarvfel i bokföringen och sedan dess har jag gått igenom alla noteringar de senaste fyra månaderna och har redan hittat åtta fel till. Stupido! Hur ska jag någonsin kunna lita på att min son sköter bokföringen korrekt?
– Åh, det är enkelt. Du har uppenbarligen inte läst min senaste bok Summa de arithmetica, geometria, proportioni et proportionalita¹, med förord av självaste Leonardo Da Vinci. Den är etta på alla försäljningslistor i den katolska världen och jag slår vad om att den kommer att hålla sig kvar åtminstone de närmaste två-tre hundra åren.
– Hur skulle den kunna hjälpa mig? Även om min son lär sig räkna kommer jag ändå behöva dubbelkolla allt. Jag kommer att ligga sömnlös om nätterna av oro.
– Contrario! Ett avsnitt handlar nämligen om det allra senaste från Venezia; dubbel bokföring.
– Che cosa?
– Signor Bocelli, i stället för att bara skriva upp transaktionerna i en bok som Ni gör har man flera bokföringskonton med vardera två sidor: debet och kredit. Varje affärstransaktion bokförs på två olika konton – på debetsidan på det ena och kreditsidan på den andra. Facile!
– Det blir ju dubbelt så mycket jobb! Min son är långsam nog på att räkna som det är utan att han ska behöva räkna dubbelt så mycket! Det var det dummaste jag har hört!
– Tvärt om. Det fina med la canzone di corvo är att debet och kredit alltid går ihop. Metoden är självkontrollerande! Om tillgångarna inte är lika stora som skulder plus eget kapital vet du att något är fel, men däremot om balansräkningen balanserar kan du sova gott på nätterna.
– Äh, det är enklare att bara räkna rätt från början! Broder Luca får ursäkta, men nu har jag ytterligare 20 månaders transaktioner att tugga mig igenom — det kommer att ta veckor, så jag har vare sig tid att läsa böcker eller utföra dubbelarbete!
Där lämnar vi våra italienska vänner och denna helt autentiska scen för att istället återvända till Jeffs föreläsning i ett decembergrått Stockholm. En fördel med att skriva automatiserade test för all sin kod är alltså att man är hyfsat säker på att man inte har förstört något allvarligt när man gör förändringar. The team is oozing confidence, som Jeff uttryckte det. Trygghet ger handlingskraft.
Det finns andra fördelar, säger de som skriver utvecklartester: Om något går sönder så behöver man inte sitta i timmar eller dagar för att försöka hitta buggen. Dina test pekar ut var koden (eller testen) behöver ändras. För att kunna skriva ett automatiserat utvecklartest måste du skriva kod som är testbar, vilket automatiskt medför en lägsta kvalitetsnivå på designen.
Sensmoral: börja genast att jobba testdrivet för att rädda vår yrkesheder – ekonomerna skrattar ju åt oss!
Om automatiserade tester och testdriven utveckling
Man kan kategorisera automatiserade test på olika sätt. Ofta brukar man prata om enhetstester (unit tests) som testar en liten del av koden till skillnad från funktionella test (functional tests) som testar på högre nivå och spänner över en större del av systemet. Här hamnar man ofta i teoretiska och irrelevanta diskussioner kring vad som är vad. Undvik den fällan!
Intressantare är att dela upp testen i snabba test (som varje utvecklare kan köra ofta på sin egen dator) och långsamma test, exempelvis prestandatest, som skulle ta för lång tid att köra lokalt och som man istället lägger på en central server och kör så ofta som det är praktiskt; till exempel varje gång en ny version av mjukvaran har byggts eller varje helg.
Det kan också vara relevant att skilja på utvecklartester som utvecklaren själv skriver till skillnad från acceptanstester som produktägaren eller QA-avdelningen specificerar.
Testdriven utveckling (Test Driven Development, TDD) är ett begrepp som har olika betydelser. Den oortodoxa definitionen är att man skriver automatiserade tester i samband med produktionskoden – koden designas för att vara testbar. Motpolen är det vi kallar strikt TDD, där man följer tre enkla men hårda regler:
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
I mitten finns kanske den vanligaste definitionen: att varje test skrivs innan den kod som det ska testa (det vill säga att testen driver utvecklingen framåt). Det låter konstigt att jobba så innan man inser att testen i själva verket är en specifikation av hur koden ska bete sig, men till skillnad från en specifikation skriven i Word så kan man dessutom använda den för att verifiera att koden uppfyller kraven, helt automatiskt, gång på gång.
Gustaf Brandberg är den av Citerus grundare som var sämst på att programmera och fick därför bli VD. Han är bättre på att skriva klatchiga PNEHM!-artiklar än på att skriva automatiserade utvecklartester, så var inte rädd för att gå i polemik med honom på [email protected].
Fotnot
¹ Prestigelöshet är ju ett av Citerus fem värdeord, men tydligen var inte ödmjukhet en dygd på 1400-talet. Bokens titel kan översättas med ungefär: “Allt om aritmetik, geometri och proportioner”.
