And now the end is near

Jag närmar mig slutet på Test Driven Development by example (Kent Beck) och fastnar för några bitar i kapitel 32, Mastering TDD, i stycket om för vem eller vilka TDD är avsett. Förresten är 32 ett bra kapitel som ger svar på, eller i alla fall lite underlag för egna avväganden, många frågor man kanske ställer sig om TDD. Anyway, det jag fastnade lite för var följande:

However, those whose souls are healed by the balm of elegance can find in TDD a way to do well by doing good

Det kändes gott i själen på något sätt. För det är ju … fint att göra gott.

TDD is also good for geeks who form emotional attachments to code. One of the great frustrations of my young engineer’s life was starting a project with great excitement, then watching the code base decay over time. A year later I wanted nothing more than to dump the now-smelly code and get on to the next project. TDD enables you to gain confidence in the code over time. As tests accumulate (and your testing improves), you gain confidence in the behavior of the system. As you refine the design, more and more changes become possible. My goal is to feel better about a project after a year than I did in the starry-eyed beginning, and TDD helps me achieve this.

Det är inget dumt sätt att tänka, faktiskt. Du kanske inte kan göra världen perfekt, men du kan alltid göra något. Och där har du också det här med att jobba i små, små steg. Envisas med det ett tag så kommer du en dag att upptäcka att du vandrat jorden runt. Utan upplevelse av ansträngning.

Men nog med filosofi … nu blir det promenad till kontoret.

Tankar kring att jobba testdrivet

Innan jag tagit mig samman och stigit upp i morse låg jag och tänkte på testdriven utveckling, funderade på vad jag vill, kan och ska säga om det hela till teamet på tisdagens eftermiddagssession. Insåg lite väl sent att jag behöver förbereda mig inför detta eftersom det är just en session och jag nog förväntas föreläsa lite. Ämnet är ”Approach to test driven development” och sessionen är bokad på en timme men omfattar även ett annat ämne (som jag dock tror kommer att vara snabbt avhandlat). Undrar om jag borde göra några bilder till det, kanske?

Varför jobba testdrivet? Det handlar delvis och förstås om att säkra kvalitén, både vid den ursprungliga utvecklingen och vid framtida underhåll av koden. Testerna utgör också dokumentation av funktionaliteten, genom att den berättar om hur det är tänkt att koden ska fungera. Men det är inte bara det där klassiska om kvalité på existerande kod, för delvis handlar testdrivet också om att uppmuntra bra design – för att skriva tester behöver man tänka efter före, inse vad som faktiskt är viktigt. Vilken funktion man ska ha och hur den ska kunna testas/verifieras. Och då nästan tvingas man strukturera koden på ett sätt så att den blir testbar. Och eftersom du skriver testerna först, innan någon kod är skriven, så blir du inte styrd av en existerande, möjligen dålig, design. Det blir rätt och bra från början.

Som jag ser på saken hamnar man rent generellt i en god spiral när man jobbar testdrivet. Man uppmuntrar till bra (eller i alla fall renare och därmed bättre) design, dokumenterar funktionaliteten samt säkerställer densamma.

Sedan man väl fundera på det hur det går att applicera de testdrivna tankarna på just min och vår verklighet, i vardagen. Jag tror att det är nästan omöjligt att fullt ut använda testdriven metodik eftersom vi ju inte jobbar så agilt (lättrörligt) som många av oss skulle önska. Processer, processer, processer. Och de här processerna i kombination med geografisk utspriddhet och utvecklarnas relativa oerfarenhet gör att man behöver göra och dokumentera design på en ganska detaljerad nivå. Det är ett frustrerande arbetssätt för när man gör den där designen så gör man ju nästan hela jobbet ändå – och det bara för att kunna skriva ned vad man gjort, d.v.s. vad utvecklaren ska göra. Eller förlåt, det här handlar nog när jag tänker efter mer om programmerare än utvecklare.

Men min tro här kan förstås också bottna i omotiverad pessimism och svårigheter att lita på andras förmåga. Det går förmodligen att göra mycket mer än vad jag tror och det är väl något jag får försöka ta med mig, diskutera med kollegorna och uppmuntra dem att fundera på. Att försöka få alla att jobba eller i alla fall tänka testdrivet, om än inte i absurdum – det ska ju ändå göra saken bättre. Vi måste vara pragmatiska och komma ihåg att varje litet steg är ett steg i rätt riktning.

Där jag främst ser att vi kan jobba testdrivet är väl i underhållet av applikationen. Att vi när det kommer in en felrapport först skriver en test som bekräftar att felet existerar, samt kanske även kod som testar närliggande funktionalitet – i den mån den inte redan finns. Det är ju inget ovanligt fel att man testar precis exakt det som är fel, men inte det som är rätt. Vilket emellanåt gör att felet visserligen blir rättat, men rättningen medför nya fel som nedlusar den tidigare felfria koden med fel. Typ ungefär så. Jag gillar negativ testning, och betraktande av saker ur flera aspekter. Jag kollar och dubbelkollar de flesta svar jag tvingas leverera. Och så gör jag även när jag jobbar, så klart. Jag testar från flera håll när det går.

Well, nu har jag skrivit ned lite av vad jag funderat och funderar på. Kommentera gärna – feedback är bra! Jag borde nog ha tänkt på att blogga om det här för länge sedan för då hade jag haft en större chans att få in kommentarer jag kunde ha nytta av i mitt faktiska arbete. Som det är nu tror jag det är få intresserade av ämnet som kommer att hinna läsa detta. Men man vet aldrig – om man inte lägger ut någon krok blir det svårt att få napp, som jag brukar säga. Eller inte.

Själv ska jag nu gå upp och sätta mig vid poolen, med mina slipade solglasögon och båda böckerna om testdriven utveckling. Kanske även baddräkten, förresten.

Bokbeställning: Testdriven utveckling

Igår beställde jag två böcker om testdriven utveckling:

• Test Driven Development: By Example (Kent Beck)
• Test-Driven Development: A Practical Guide (David Astels)

Den här gången var det dock inte jag som betalade.

Medan jag väntar läser jag min Pragmatic Unit Testing. Den känns så där, än så länge, men jag har inte hunnit så långt. Jag skulle hellre läsa Piraterna, men den boken råkade jag ju glömma ute i förorterna förra helgen.