Man kan sige, at det er noget sent i forløbet, at vi får taget os sammen til at skrive testen - vores system har, for størstedelen af det, været i produktionslignende pilotdrift i noget, som efterhånden begynder at ligne et års tid. Når vi aldrig fik skrevet en formel test i første omgang, så er det nok fordi, at applikationen er groet langsomt frem, og pilotdriften er noget, som næsten er kommet snigende. Men nu, hvor applikationen bliver godt og grundigt hovedrenoveret, så er det en glimrende lejlighed til at få skrevet sådan en test.
Vi, der skriver testen, kender applikationen så godt, at vi sidder og skriver den "kold". Vi sidder altså ikke med applikationen kørende i baggrunden, imens vi skriver - vi skriver bare testen direkte fra hovedet og ned på papiret. Derfor kom det også som noget af et chok for mig, at min kollega pludselig kigger op og siger: "Bjarne, jeg har fundet en større fejl!" Jeg mener, fejl det er da noget, som man finder, når man prøver at bruge applikationen, ikk'? Og den har været i drift igennem længere tid uden problemer - så hvordan kan han sidde der, og så lige ud af den blå luft sige, at der er en fejl?!?
Men der var en fejl. En måde at bruge applikationen på, som ville give vildledende resultater. Det er nærmest tilfældigheder, som har gjort, at vi ikke er rendt ind i den - og vi introducerer lige om lidt ny funktionalitet, som ville have gjort det ganske sandsynligt, at rigtigt mange ville have oplevet det i praksis. Den eneste grund, til at vi fandt den nu, var, at vi, i og med at vi skulle skrive testen, havde tvunget os selv til at sætte os ned, og tænke applikationens brug systematisk igennem.
Micheal Feathers beskriver det samme fænomen i sin blog-post "The flawed theory behind unit testing". Det spørgsmål, som han stiller sig selv, er egentlig meget simpelt: Hvordan kan det være, at programkode, som er blevet unittestet, indeholder færre integrationsfejl? Og her tænker han ikke på fejl, som kunne være fundet af en unittest, men som på grund af utilstrækkelig unittest, først bliver fundet i integrationstesten - næh, det som undrer ham er, at det at lave unittesten tilsyneladende forhindrer flere fejl i at opstå, end hvad selve testen rent faktisk verificerer. Læs selv hans blog, den er kort og letlæst, og den kommer også forbi andre emner, som f.eks. TDD.
Michaal Feathers konklusion er, at unittestens umiddelbare værdi ikke så meget af selve testen (selvom han ikke er blind for, at automatiseret test øger muligheden for at lave efterfølgende ændringer på en sikker måde), men derimod at det tvinger os til at sætte os ned og tænke systematisk over det, som vi vil lave (eller måske lige har lavet). Han siger selv afslutningsvist:
The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.
Det var det, som min kollega oplevede - og jeg har selv oplevet det, når jeg har siddet og skrevet unittest: Pludselig finder man grundlæggende logiske fejl i det, som man har implementeret - altså ikke fejl i implementationen, men i præmisserne for den. Jeg har bare ikke rigtigt tænkt over det, førend Michael Feathers satte sin finger på det.
Kelly Waters er inde på noget af det samme i sin blog-post "Agile project initiation": Her beskriver han de lange dokumenter, som mange projektmodeller foreskriver, at man udarbejder inden et projekt starter op - dokumenter på over 50 sider, som det er vanskeligt at få nogen til at læse. De fleste folk, som skriver noget med "agil" i deres CV, vil her sige, at hvis der ingen er, som læser det, så skal man helt lade være med at skrive det. Men Kelly Waters bemærker, at det giver ham værdi - det tvinger ham nemlig til at tænke projektet igennem på en systematisk måde. Hans bud på, hvad man så gør, er at lave det som en powerpoint-præsentation, for dels kommer han igennem de samme overvejelser, og dels så kan han bruge det, som en diskussionsoplæg, og derved ydermere få en feedback, som han ikke oplevede ved de lange dokumenter. Powerpoint virker for ham, men pointen er vel, at alt hvad der ville tvinge ham til at arbejde sig systematisk igennem overvejelserne, ville være lige så godt.
Så, stop op, og giv dig tid til at tænke dig godt om - det er bedre, at komme stille og roligt afsted i moderat fart i den rigtige retning, end det er straks at sprinte afsted i den forkerte. Men det er ingen opfordring til at tage en "morfar" i hængekøjen - det virker kun, hvis du tvinger dig selv til at arbejde dig systematisk igennem det.
PS: Måske er det derfor, at COBOL programmer stadig er så udbredte - der er man pinedød nødt til at tænke sig godt om, inden man gør noget! :-)
