Acceptanstestdriven utveckling

För ungefär en vecka sedan deltog jag i en webbkurs i acceptanstestdriven utveckling (ATDD). Kursen anordnades av Elisabeth Hendrickson för Learning Tree och var ett steg i att utforma en interaktiv webbkurs som, i hennes ord, inte sög. Utrustad med webbkamera, mikrofon och tillhörande lurar samt viss nervositet inför vilka deltagare som skulle delta och vilka frågor som skulle ställas kopplade jag upp mig mot den WebEx-tjänst som skulle vara värd för ”konferensen”. Eftersom jag satt hemma i lugn och ro och hade haft hela dagen på mig att förbereda och testa kamera och mikrofon, kursen började kl 08.00 PDT (16.00), var det inget strul med den biten till skillnad från de flesta andra. Konstigt nog envisades det med att använda virtuella maskiner och diverse andra konstiga uppsättningar för att krångla till det hela, ändå kom vi igång ungefär vid utsatt tid.

Själva kursen började med att visualisera konceptet med ATDD som jag inte riktigt greppat vad skillnaden skulle vara mot testdriven utveckling (TDD). I figuren som visades uppfattade jag ATDD som ett yttre lager på TDD som gjorde det tydligare för beställare vilka krav som implementerades och vad som kunde saknas ur kravsynpunkt.

Processen börjar alltså med diskussion, beställare och leverantör träffas och dsikuterar vad som ska göras, Skapar en produkt-backlog. Därefter följde den mest intressanta biten och där kursen fokuserades, destillera. Destilleringen innebär själva utformandet av testfallen i acceptanstestform. Därefter följde utveckling enligt TDD. Till sist fanns steget demo och därefter åter till diskussion.

Under kursen användes ett ramverk som medger skrivande av testfall på en hög nivå. Ramverket hjälper sedan till med att skapa automatiska testfall på enhetstestnivå, självklart sker skapandet inte helt automatiskt, fortfarande måste någon koda referenser, nyckelord och funktioner. Det fina med kråksången är dock att det är mycket lättare att visa hur testfallen och därmed kravbilden ser ut för beställaren. På så sätt används testfallen som en form av diskussionsunderlag där man tillsammans med beställare kan identifiera problem och bryta ner funktioner samt finna ny funktionalitet.

I det stora hela var det en givande kurs som lyckades ge mig en inblick i ATDD på relativt kort tid. Något som dock är irriterande för mig är när alltför mycket tid går åt till kodfipplande. Det hände några gånger att kursledaren blev för involverad i att lösa syntaxfel, vilket i rätt mängd kan vara lärorikt men också alldeles för lätt blir tråkigt att beskåda.
Det visade också på ett problem som jag funderat en del kring; det är inte alltid det är helt klart om det är testfallet eller koden som är fel. Testfallet är alltså den kod som utgör testfall, kod är det som utgör produkten. Viktigt i dessa situationer är att den som utvecklar eller åtminstone kör testfallen är helt bevandrad i både testfall och kod. Under kursen var detta ingen problem eftersom Elisabeth utvecklat både den simpla koden och testfallen varför hon lätt, säkert delvis av erfarenhet också, kunde identifiera att en förändring fått som konsekvens att ett icke direkt relaterat testfall slutat fungera var beroende på utformningen av testfallet och inte koden i sig.

Vad gäller formen för kursen var det det gamla vanliga som gäller vid webbkonferenser, dåligt ljud från flera deltagare och svårt att veta vem som talade. För att få det att fungera gäller det nog att mer strikta regler för hur man ska samverka är satta innan man startar, hur man får ordet och liknande. Dessutom borde man gå igenom hur man låter i de andra ändarna för att man ska veta hur högt man ska prata o.s.v, saker som man inte tänker på att man justerar när man sitter samlade vid ett bord.