TDD vs BDD

Test-Driven Development (TDD) er en programmeringstilgang, der understreger at skrive tests, før man udvikler kodefunktionen. Denne metode sikrer, at koden opfylder de ønskede krav og hjælper med at forhindre fejl.

📚 Oprindelse

Test-Driven Development (TDD) blev udviklet af Kent Beck i slutningen af 1990'erne som en del af Extreme Programming.

TDD følger en cyklus med at tilføje en test, få testen til at fejle, skrive kode for at få testen til at passere og derefter refakturere koden.

TDD fokuserer på at teste små enheder af kode ad gangen, hvilket sikrer, at systemet bliver bygget inkrementelt og med høj testdækning.

Også kendt som 'Red-Green-Refactor' cyklussen, hvor koden skrives for at få den fejlede test til at passere og derefter refaktoreres for at forbedre strukturen.

Behavior Driven Development (BDD) er en softwareudviklingsproces, der sigter mod at forbedre samarbejdet. Det fokuserer på at definere systemets adfærd fra brugerens perspektiv ved hjælp af specifikationer skrevet i et naturligt sprog.

BDD udviklede sig fra Test Driven Development (TDD), men med en mere brugerorienteret tilgang til krav og systemadfærd. Denne tilgang hjælper med at sikre, at softwareudviklingen er bedre tilpasset slutbrugerens forventninger og behov.

Overgangen fra TDD til BDD er kendetegnet ved et skift i fokus fra test, der kun er baseret på kode, til test, der er baseret på systemets adfærd fra brugerens perspektiv. Dette muliggør en dybere forståelse af brugerens behov og hvordan systemet skal opføre sig for at imødekomme dem.

BDD bruger Gherkin-sproget til at skrive specifikationer på en måde, der er forståelig for både tekniske og ikke-tekniske teammedlemmer. Dette gør det muligt for specifikationerne at fungere som en fælles sandhedskilde, hvilket forbedrer kommunikationen og reducerer misforståelser.

BDD fremmer en delt forståelse af den forventede softwareadfærd, hvilket sikrer, at alle involverede, herunder ikke-tekniske interessenter, har en klar forståelse af projektets mål. Denne tilgang hjælper med at undgå uoverensstemmelser mellem hvad forretningen har brug for og hvad udviklingsteamet leverer.