Hvad er TDD og ATDD?

I denne artikel fremhæver vi ligheder og forskelle mellem to populære testmetoder, der almindeligvis er kendt som TDD og ATDD.

TDD står for testdrevet udvikling, mens ATDD står for accepttestdrevet udvikling. Det er afgørende for testprofessionelle at forstå, hvordan disse to testmetoder fungerer, og dette indlæg vil være en grundbog, så du kan komme i gang med din opdagelse af begge. Du vil forstå TDD vs ATDD.

Hvad er testdreven udvikling (TDD)?

TDD er et system til udvikling af software efter Extreme Programming (XP)-principperne, men med tiden er det dog blevet udspundet som en selvstændig softwareudviklingsteknik.

I TDD udføres enhedstest direkte på kildekoden.

Først skriver testeren en automatiseret testcase, som definerer den ønskede funktion, som systemet ideelt set skal udføre, men udformer bevidst testcasen på en sådan måde, at den ikke kan opfyldes af systemet i dets nuværende tilstand.

For det andet noterer udvikleren årsagerne til, at systemet ikke opfyldte testen, og skriver den kode, der er nødvendig for at refaktorisere systemet, så det kan bestå den i andet forsøg. Denne proces er opsummeret i nedenstående grafik.

D TDD-processen fortsætter på denne måde og zigzagger mellem fiasko og succes, således at hver iteration presser systemet til dets grænser og derefter hjælper det med at overvinde dem gennem den feedback, der genereres.

D TDD er et eksperiment i frivillig fiasko, og det kræver en del mod at sætte sig ind i denne kontra-intuitive teknik. Men når du først har gjort det, vil du blive belønnet med en enkel, men meget effektiv metode til at bekæmpe frygten for fiasko under testning og samtidig forbedre det arbejde, du udfører.

Hvad er Acceptance Test-Driven Development (ATDD)?

ATDD er en samarbejdsbaseret testmetode, som tvinger alle de personer, der er involveret i skabelsen af ny software (f.eks.f.eks. testere, udviklere og brugere) til som et team at definere de acceptkriterier, som systemet skal opfylde i de tidlige udviklingsfaser.

Pointen med dette trin er at sikre, at alle disse interessenter er enige om de vigtigste mål for projektet, især med hensyn til den funktionalitet, som slutbrugeren kan forvente. I denne fase af ATDD kan teknikker som brugerpersonas og brugerhistorier være meget nyttige.

Når accepttesterne endelig køres på systemet, noteres fejl, og udviklerne refaktoriserer derefter defekte komponenter ved at skrive den kode, der er nødvendig for at opfylde acceptkriterierne ved næste forsøg.

Denne proces udføres iterativt, normalt i slutningen af hvert sprint, indtil det endelige produkt er klar til implementering. Grafen nedenfor forklarer dette.

ATDD giver teamet et klarere billede af, hvordan slutproduktet vil fungere, så alle kan holde fokus på de langsigtede mål i stedet for at fortabe sig i de enkelte kodelinjer.

Sammenfattende

Nu har du en god forståelse for de grundlæggende forskelle mellem TDD og ATDD. Disse to testmetoder er nært beslægtede, men ATDD inkluderer også accepttest i processen og lægger mere vægt på samarbejde i teamet end TDD.

Både tilgange passer fint ind i agile principper, da begge tilskynder til indsamling af feedback for at bygge videre på dine tidligere fejltagelser. Efterhånden som du løbende refaktoriserer systemet og løser de problemer, du stødte på i det foregående forsøg, hjælper disse metoder dig med at udvikle et mere værdifuldt slutprodukt på en inkrementel måde.

Gå med i 60.000+ Subscribers

For seneste blogs, opdateringer fra branchen og eksklusive tips.

*Din e-mail er sikker hos os, vi hader også spam