BDD vs TDD

Behavior Driven Development (BDD) is een softwareontwikkelingsproces dat gericht is op het verbeteren van de samenwerking. Het richt zich op het definiëren van het gedrag van het systeem vanuit het perspectief van de gebruiker, met behulp van specificaties geschreven in natuurlijke taal.

BDD is ontstaan uit Test Driven Development (TDD), met een grotere focus op gebruikersvereisten en systeemgedrag. Deze benadering helpt te garanderen dat de softwareontwikkeling beter aansluit bij de verwachtingen en behoeften van de eindgebruiker.

De overgang van TDD naar BDD wordt gekarakteriseerd door een verschuiving van code-gebaseerde testen naar gedragsgebaseerde testen van het systeem vanuit het gebruikersperspectief. Dit vergemakkelijkt een dieper begrip van de gebruikersbehoeften en hoe het systeem zich moet gedragen om die te vervullen.

BDD maakt gebruik van de Gherkin-taal om specificaties op te stellen die begrijpelijk zijn voor zowel technische als niet-technische teamleden. Dit maakt het mogelijk om specificaties als een gedeelde waarheid te gebruiken, waardoor communicatie wordt verbeterd en misverstanden worden verminderd.

BDD bevordert een gedeeld begrip van het verwachte gedrag van de software, zodat iedereen, inclusief niet-technische belanghebbenden, een duidelijk begrip heeft van de projectdoelen. Deze benadering helpt discrepanties tussen wat het bedrijf nodig heeft en wat het ontwikkelingsteam levert te vermijden.

Test Driven Development (TDD) is een programmeeraanpak die de nadruk legt op het creëren van tests voordat de functionaliteit van de code wordt ontwikkeld. Deze methode zorgt ervoor dat de code voldoet aan de gestelde eisen en helpt bij het voorkomen van fouten.

📚 Oorsprong

Test Driven Development (TDD) werd ontwikkeld door Kent Beck aan het eind van de jaren '90 als onderdeel van Extreme Programming.

TDD volgt een cyclus van een test toevoegen, de test laten falen, code schrijven om de test te laten slagen en vervolgens de code refactoren.

TDD richt zich op het testen van kleine eenheden code tegelijk, zodat het systeem incrementeel wordt opgebouwd met een hoge testdekking.

Ook wel bekend als de 'Red-Green-Refactor' cyclus, waarbij code wordt geschreven om de mislukte test te laten slagen en daarna wordt gefactoreerd om de structuur te verbeteren.