Disse 3 teknikkene er oftest brukt i forbindelse med smidig baserte metoder (slik som Scrum og Kanban), men kan også brukes i fossefall prosjekter. Alle kan brukes for å utforme krav - som kan igjen brukes til å lage test caser – som deretter kan bli automatisert. De brukes som regel sammen. Jeg skal her forsøke å forklare hvordan de fungerer. Til slutt vil jeg nevne noen tenkte fordeler og ulemper knyttet til teknikkene.
Jeg kommer til å gå mer i detalj i senere innlegg, for jeg merker at her er det nyanser og det er absolutt ingen fasitsvar her.
TDD: Brukes til å skrive unit tester, for så å skrive nok og riktig kode slik at testen virker. Dette gjøres igjen for neste kode-enhet og så gjentas prosessen videre i utviklingen for hver nye kode-bit. TDD er altså en inkrementell prosess. Metoden er først kjent i forbindelse med «eXtreme Programming» rammeverket (XP), som er en inkrementell og iterativ metode.
BDD: Ligner veldig på TDD og baserer seg på de samme prinsippene. Forskjellen er at TDD baserer seg på å skrive kode, mens BDD er hendelsesbasert. Det vil si at du kan si noe slik som «Hvis jeg er logget inn – og hvis jeg klikker på ordrehistorikk «knappen» - så skal jeg kunne se en liste med alle ordrer siste 6 mnd.» Altså hvordan brukerne samhandler med løsningen eller hvordan løsningen oppfører seg. Eksempel på standardspråk for BDD er Gherkin, som kan uttrykke scenarioene på ett beskrivende språk . Med et slikt språk kan både tekniske ressurser og forretningen ha bedre felles forståelse for kravene.
ATDD: Dette er akseptansekravene. De kan være mer eller mindre detaljerte. Akseptansekravene er som oftest mer enn bare HVORDAN systemet skal oppføre seg. Akseptansekrav i KAN praksis være det samme som står beskrevet i test BDD scenarioene. Men som regel er det mer fokus på HVA systemet skal gjøre og på flere kvalitetsegenskaper enn det BDD dekker.
Jeg skal skal som sagt ta opp dette teamet i senere artikler, så følg med. Men her er noen fordeler og ulemper med TDD og BDD.
TDD Fordeler:
- Kan fange opp defekter tidlig i prosessen
- Bidrar til å dokumentere kode med faktiske kjørbare eksempler
- Hjelper programmererne til å få god innsikt i egen kode
- Bygges i praksis inn regresjonstesting tidlig i prosessen
- Sørger for oppbygning av fungerende programvare i små trinn (lettere enn å løse problemer i etterkant)
TDD Ulemper:
- Utfordrende å lære
- Kan i noen tilfeller være vanskelig å skrive tester
BDD Fordeler:
- Bygger inn en form for automatisk dokumentasjon, som kan brukes til å dokumentere ytterligere
- Gjøre det lettere for nye team medlemmer å skjønne løsningen
- Får et bedre grunnlag for å gjøre manuell og utforskende testing
BDD Ulemper:
- Kan være utfordrende i forhold til kommunikasjon internt i teamet og på tvers av roller
- Vanskelig hvis kommunikasjonen mellom bruker og utvikler ikke fungerer godt