Hvis du er bekendt med TDD, så er ATDD på en måde TDD med et højere testniveau og med flere involverede interessenter, med andre ord er det mere en accepttest end en enhedstest. Hvis du vil vide mere om TDD, så tjek venligst følgende indlæg:
Acceptance test-driven development (ATDD) er en udviklingsmetodologi baseret på kommunikation mellem forretningskunderne, udviklerne og testerne. ATDD omfatter mange af de samme metoder som specifikation ved eksempel, adfærdsdrevet udvikling (BDD), eksempeldrevet udvikling (EDD) og supportdrevet udvikling også kaldet story testdrevet udvikling (SDD). Alle disse processer hjælper udviklere og testere med at forstå kundens behov forud for implementeringen og gør det muligt for kunderne at tale i deres eget domænesprog.
Tidligt implementeret inden for agile teams er ATDD en praksis, hvor forretningsanalytikere, udviklere ,testere og brugerne arbejder sammen om at definere hver story (eller feature) acceptkriterier i en tidlig fase af udviklingsprocessen (før kodningen begynder). Denne fremgangsmåde gør det muligt for alle interessenter at have og opretholde det samme niveau af forventede resultater, før udvikleren begynder at kode.
Jeg ved, at vi alle har hørt denne stereotype om, at “udviklere er ligeglade med specifikation og testere vil ikke lave automatisering”, men med ATDD vil dette spare en masse spildt tid og penge ved at sikre, at udviklerne er mere involveret i de tidlige stadier af specifikation og testerne automatiserer accepttests.
Hvordan ATDD er implementeret i “det virkelige liv”?
Bruger du SCRUM? Hvis ja, så gør du allerede det meste af arbejdet i ATDD. hvis ikke, så må det følgende eksempel nære din nysgerrighed :
Eksempel
Lad os antage, at produktejeren eller kunden har anmodet om følgende funktion i vores mobilapplikation: “Efter at have gennemgået denne anmodning med hele teamet (forretningsanalytiker, udviklere, testere…) og med flere detaljer tilføjet til historien eller funktionen, vil vi have nogle “accept” eller “funktionelle” tests, der ligner dette (bemærk venligst, at dette blot er et eksempel, mange accept tests mangler for denne funktion):
- Acceptkriterium 1: Applikationen accepterer valgfrit login/password til login
- Acceptkriterium 2: Knappen bypass giver brugeren mulighed for at bladre i applikationen uden login.
- Acceptkriterium 3: Når knappen bypass er valgt, gemmer eller viser applikationen ikke brugerspecifikke oplysninger.
- Acceptkriterium 4: Når login/password anvendes, skal applikationens GUI tilpasses til brugerindstillingerne.
Fordele
1- Tilpasning mellem klient og sælger : Ved at have acceptkriterierne ovenfor som inputinformation er vi (alle teammedlemmer) nu sikre på, at applikationen bevarer sin login/password-funktionalitet og kun tilføjer en knap, der gør det muligt for brugeren at omgå login-skærmen.
2- Kvalitet og omkostningseffektivitet: Ovenstående tests kan nemt automatiseres, selv før udviklerne begynder at kode.
3- Time to Market: Når testene er implementeret, kan udviklerne validere deres krævede opgaver, før de meddeler, at de er færdige.
ATDD kræver ingen specifikke værktøjer. Det er vigtigt at vide, at IKKE alle accepttests skal automatiseres. Automatisering af dine tests afhænger af flere aspekter såsom: tekniske udfordringer, deadline og omkostninger.
Nogle værktøjer anbefales?
ATDD kræver ikke nogen specifikke værktøjer. Det er vigtigt at vide, at IKKE alle godkendelsestests skal automatiseres. Automatisering af dine tests afhænger af flere aspekter såsom: tekniske udfordringer, deadline og omkostninger.
I dette afsnit vil jeg blot give dig et overblik over de mest anvendte automatiseringsværktøjer på ATDD:
FitNess: Den fuldt integrerede standalone wiki og accept testramme
Robot framework: Generisk testautomatiseringsramme til accept test og accept testdrevet udvikling (ATDD)
Calabash: Automatiseret acceptprøvning til mobilapps – Vær opmærksom på, at denne ramme muligvis ikke understøtter den seneste OS-version (over Android O )