BDD: Revolutionen er startet!
Som skrevet tidligere, skal vi i vores projekt til at omskoles til at anvende Behaviour-Driven Developement (BDD), som dybest set er en sammenkobling af Domain-Driven Design (DDD) og Test-Driven Design (TDD). Jeg har derfor besluttet at dedikere en del af min sommerferie til at sætte mig ind i begreberne - for godt nok havde jeg en ide om hvad de forskellige ting er, men jeg ville være helt sikker på, at jeg forstået det korrekt. I de følgende indlæg vil jeg gøre rede for de ting, som jeg er stødt på.
Agil udvikling har en række karakteristika som passer rigtig godt sammen med TDD - egentlig virkede det for mig lidt underligt, at de skulle passe godt sammen, fordi TDD for mig lød som en masse design up-front (BDUF). Jeg har tidligere haft en vis anti-pati mod TDD, fordi jeg bruger meget prototyper - og derfor virkede det som en modsætning at skrive test, før jeg havde fundet ud af hvordan jeg ville lave det. Hvordan kan man skrive tests før man ved, hvordan man ville lave det?
For at starte et sted, startede jeg med Wikipedia’s side om BDD og læste alle links grundigt igennem - og her skete den første åbenbaring: Glem alt om at kalde noget for test - vi laver ikke unit-tests for at teste - vi laver unit-tests for at specificere system-adfærden. Jeg tror den sætning er den vigtigste overhovedet - det var i hvert fald den, der åbnede en prås for mig. Pludselig gav sammenhængen mening - jeg havde siddet og kørt rundt i cirkler med tests af implementationen og ikke adfærden af programmet.
Det viser sig (som flere af grundlæggerne iøvrigt bemærker) at ordvalget kan være kritisk for om man forstår et koncept. Når alt i en test-suite hedder noget med ‘test’, så bliver man fokuseret på test-delen. Man spørger sig selv: “Hvordan kan jeg sikre mig at så meget af min kode bliver testet som overhovedet muligt?”, “Hvornår har jeg nok tests?” osv. En af forfatterne til Wiki-siden prøvede for eksemplets skyld at udskifte alle ord og sætninger, som indeholdet ordet ‘test’ med ‘adfærd’/'burde’ (’behaviour’/’should’) alt efter sammenhængen. Det gjorde udslaget for mig. Det jeg fremover skal koncentrere mig om er, “hvad vil jeg have programmet til at kunne?”, “Hvorkan bør det opføre sig?”.
For øvelsens skyld, satte jeg mig ned med et simpelt problemområde og skrev specifikationerne til, hvordan jeg forventede, at systemet skulle opføre sig (dybest set bare et objekt med en liste af en anden type objekter). Eksemplet har virkelig givet mig blod på tanden - og i de næste par indlæg vil jeg prøve at beskrive processen.