Wat zijn TDD en ATDD?

In dit artikel belichten we de overeenkomsten en verschillen tussen twee populaire testmethoden die algemeen bekend staan als TDD en ATDD.

TDD staat voor test-driven development, terwijl ATDD staat voor acceptance test-driven development. Begrijpen hoe deze twee testbenaderingen werken is van cruciaal belang voor testprofessionals en deze post zal een primer zijn om u op weg te helpen bij uw ontdekking van beide. U zult begrijpen TDD vs ATDD.

Wat is Test-Driven Development (TDD)?

TDD is een systeem voor het ontwikkelen van software volgens de principes van Extreme Programming (XP), maar in de loop van de tijd is het uitgelopen tot een onafhankelijke software-ontwikkelingstechniek.

In TDD worden unit tests direct op de broncode uitgevoerd.

Eerst schrijft de tester een geautomatiseerde testcase waarin de gewenste functie wordt gedefinieerd die het systeem idealiter zou moeten uitvoeren, maar hij ontwerpt de testcase met opzet zodanig dat deze niet door het systeem in zijn huidige staat kan worden vervuld.

Tweede noteert de ontwikkelaar de redenen waarom het systeem niet aan de test voldeed en hij schrijft de code uit die nodig is om het systeem te herformuleren en het in staat te stellen de test bij de tweede poging te doorstaan. Dit proces is samengevat in de onderstaande grafiek.

Het TDD-proces gaat op deze manier verder, zigzaggend tussen mislukking en succes, zodat elke iteratie het systeem tegen zijn grenzen duwt en het vervolgens helpt deze te overwinnen door de feedback die wordt gegenereerd.

Het TDD-proces is een experiment in vrijwillig falen en er is nogal wat moed voor nodig om deze contra-intuïtieve techniek in je hoofd te krijgen. Maar als je dat eenmaal doet, word je beloond met een eenvoudige maar zeer effectieve methode om faalangst tijdens het testen te bestrijden en tegelijkertijd het werk dat je doet te verbeteren.

Wat is Acceptance Test-Driven Development (ATDD)?

ATDD is een collaboratieve testmethode die alle mensen dwingt die betrokken zijn bij het maken van nieuwe software (bijv.b.v. testers, ontwikkelaars en gebruikers) om als team de acceptatiecriteria vast te stellen waaraan het systeem in de eerste fasen van de ontwikkeling moet voldoen.

De bedoeling van deze stap is ervoor te zorgen dat al deze belanghebbenden het eens zijn over de belangrijkste doelstellingen van het project, met name wat betreft de functionaliteit die de eindgebruiker mag verwachten. Tijdens deze fase van ATDD kunnen technieken als user persona’s en user stories zeer behulpzaam zijn.

Wanneer de acceptatietests uiteindelijk op het systeem zijn uitgevoerd, worden mislukkingen opgemerkt en de ontwikkelaars zullen vervolgens defecte componenten refactoren door de code te schrijven die nodig is om bij de volgende poging aan de acceptatiecriteria te voldoen.

Dit proces wordt iteratief uitgevoerd, meestal aan het einde van elke sprint, totdat het eindproduct klaar is voor implementatie. De onderstaande grafiek legt dit uit.

ATDD biedt het team een duidelijkere visie op hoe het eindproduct zal werken, waardoor iedereen zich kan blijven richten op de langetermijndoelen in plaats van zich te verliezen in afzonderlijke regels code.

In samenvatting

Nu hebt u een goed begrip van de basisverschillen tussen TDD en ATDD. Deze twee testmethoden zijn nauw verwant, maar ATDD omvat ook acceptatietests in het proces en hecht meer belang aan teamsamenwerking dan TDD.

Beide benaderingen passen goed in agile principes, omdat beide het verzamelen van feedback aanmoedigen om voort te bouwen op je eerdere fouten. Terwijl u het systeem voortdurend refactored en de problemen aanpakt die u in de vorige poging tegenkwam, helpen deze methoden u een waardevoller eindproduct te ontwikkelen op een incrementele manier.

Voeg 60.000+ abonnees

Voor de nieuwste blogs, industrie-updates en exclusieve tips.

*Uw e-mail is veilig bij ons, we haten ook spam