Het debat TDD versus BDD wordt vaak voorgesteld als het kiezen van een kant. In werkelijkheid beantwoorden ze verschillende vragen. Bij testgedreven ontwikkeling wordt gevraagd of de code doet wat de ontwikkelaar bedoelde, terwijl bij gedragsgedreven ontwikkeling wordt gevraagd of het team het überhaupt eens is over wat de software moet doen.

Om het verschil concreet te maken, bouwen we bij elke aanpak één kleine kortingsfunctie. We hebben de code uitgevoerd op Python 3.13, met behulp van de standaardbibliotheek, en de onderstaande resultaten komen uit die run. Het BDD-gedeelte gebruikt een eigen klein lopertje om het mechanisme te laten zien, dus een echt project zou een hulpmiddel zoals Komkommer gebruiken of zich in plaats daarvan gedragen.

Het korte antwoord

Testgestuurde ontwikkeling (TDD) is een codeerpraktijk. Je schrijft een kleine mislukte test, zorgt ervoor dat deze slaagt met de eenvoudigste code en verbetert vervolgens het ontwerp. Tests worden in code geschreven, en voornamelijk door ontwikkelaars. Kent Beck maakte de praktijk populair.

Gedragsgestuurde ontwikkeling (BDD) is een samenwerkingspraktijk die is voortgekomen uit TDD, en Dan North introduceerde de term. Ontwikkelaars, testers en zakenmensen zijn het eens over voorbeelden van hoe het systeem zich zou moeten gedragen, geschreven in duidelijke taal, en die voorbeelden kunnen vervolgens worden geautomatiseerd.

TDD versus BDD naast elkaar

De functie

Dit is de bedrijfsregel die we zullen implementeren: Bestellingen van 1000 of meer krijgen 10% korting. Leden krijgen 5% extra korting op deze bestellingen.

Dat klinkt misschien helder, maar het is al dubbelzinnig. Krijgt een lid dat 500 euro besteedt, 5% korting? In de zin staat ‘die bevelen’, dus we gaan ervan uit van niet. Houd dat in gedachten, want dit is precies het soort vraag dat BDD in een vroeg stadium naar voren wil brengen.

Bouw het met TDD

TDD volgt een korte lus die bekend staat als rood, groen, refactor:

Dit zijn onze tests, met één voor elke regel:

class DiscountTests(unittest.TestCase):
    def test_no_discount_below_1000(self):
        self.assertEqual(discount(999, False), 0)

    def test_ten_percent_from_1000(self):
        self.assertEqual(discount(1000, False), 100)

    def test_member_gets_extra_five_percent(self):
        self.assertEqual(discount(1000, True), 150)

Vervolgens hebben we de code in drie fasen geschreven, waarbij we na elke fase de tests hebben uitgevoerd. Een strikte TDD-sessie voegt één test tegelijk toe, en dit laat dezelfde progressie zien:

Fase 1: het eenvoudigste

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Het retourneren van nul ziet er raar uit, maar het bewijst dat de tests daadwerkelijk kunnen mislukken, en de enige test die het doorstaat is de ‘geen korting’-regel.

Fase 2: voeg de drempel toe

def discount(total, is_member):
    if total >= 1000:
        return total * 0.1
    return 0

# 3 tests, 1 failed
#   test_member_gets_extra_five_percent

Fase 3: leden toevoegen en opruimen

def discount(total, is_member):
    rate = 0.1 if total >= 1000 else 0
    if is_member:
        rate += 0.05
    return round(total * rate, 2)

# 3 tests, 0 failed

Alle drie passeren. Maar lees deze versie aandachtig. Het geeft een lid dat 500 euro besteedt een korting van 5%, wat niet is wat we dachten dat de regel betekende. Geen enkele test heeft dat geval gedekt, dus niets heeft dit gemarkeerd. TDD beschermt alleen het gedrag dat je dacht te testen. Dat is een echte beperking, en de reden waarom gesprekken over voorbeelden zo belangrijk zijn.

Waarom de cyclus ertoe doet

• Rood bewijst dat de test werkt. Een test die nooit heeft gefaald, test misschien niets.
• Groen houdt je gefocust. Je schrijft alleen de code die nodig is, waardoor over-engineering wordt voorkomen.
• Refactor houdt de kwaliteit hoog. Tests geven u het vertrouwen om het ontwerp veilig te wijzigen.
• Het heeft invloed op het ontwerp. Moeilijk te testen code is vaak te nauw met elkaar verbonden, en dat merk je meteen.

Onze pytest-tutorial laat een gemakkelijkere manier zien om dit soort tests te schrijven, en grenswaardeanalyse legt uit waarom we 999 en 1000 als waarden hebben gekozen.

Bouw het met BDD

BDD begint met een gesprek, niet met hulpmiddelen. Vaak is het een korte bijeenkomst die bekend staat als de drie amigo’s, waarbij een productpersoon, een ontwikkelaar en een tester concrete voorbeelden bespreken:

Tester:  What about a member spending 500?
Product: Good question. No discount. It has to reach 1000 first.
Dev:     And exactly 1000 counts?
Product: Yes, 1000 or more.

Die ene uitwisseling zou het probleem in onze TDD-code hebben opgevangen. Vervolgens nemen ze hun voorbeelden op in een gestructureerd formaat genaamd Gherkin:

Feature: Order discounts

  Scenario: Member reaches the discount threshold
    Given a member with a cart worth 1000
    When they view the amount to pay
    Then the amount to pay is 850

  Scenario: Member below the threshold gets no discount
    Given a member with a cart worth 500
    When they view the amount to pay
    Then the amount to pay is 500

Iedereen in het team kan dat lezen en zeggen ‘ja, dat klopt’ of ‘nee, dat klopt’. Zelfs als je het nooit automatiseert, heeft het scenario al nuttig werk verricht.

Stappen verbinden met code

Tools verbinden elke regel in duidelijke taal met een functie, een zogenaamde stapdefinitie. Om het idee te laten zien, hebben we zelf een kleine versie geschreven en het eerste scenario uitgevoerd:

@step("a member with a cart worth 1000")
def given(ctx):
    ctx["cart"] = Cart(is_member=True)
    ctx["cart"].add(1000)

@step("they view the amount to pay")
def when(ctx):
    ctx["amount"] = ctx["cart"].payable()

@step("the amount to pay is 850")
def then(ctx):
    assert ctx["amount"] == 850

# ok Given a member with a cart worth 1000
# ok When they view the amount to pay
# ok Then the amount to pay is 850

Echte tools voegen parameters toe, zodat een enkele stap zowel “1000” als “500” kan matchen, plus rapportage. Het resultaat is levende documentatie: een duidelijke beschrijving van het systeem, die luid faalt als het niet meer waar is.

Goede scenario’s schrijven

Scenario’s die klikken en veld-ID’s beschrijven, breken bij elk nieuw ontwerp en zakelijke lezers lezen ze niet meer. Bewaar de details van de gebruikersinterface in de stapcode. Deze scenario’s zijn nauw verwant aan de voorbeelden in testcase versus testscenario, en worden ook vaak gebruikt bij gebruikersacceptatietests.

Beide samen gebruiken

De twee passen op natuurlijke wijze in een ‘outside-in’-workflow:

1. Het team maakt afspraken over het gedrag en schrijft een BDD-scenario. Het mislukt, omdat er nog niets bestaat.
2. Een ontwikkelaar gebruikt TDD om de benodigde kleine eenheden te bouwen.
3. Unit-tests slagen, en uiteindelijk ook het scenario.
4. Alles draait in uw CI/CD-pijplijn.

Houd ze allemaal op het juiste niveau. Je zou een paar scenario’s moeten hebben voor belangrijk gedrag, en veel snelle unit-tests voor de details. Onze gids voor unit- versus integratietests behandelt de balans.

Gereedschap

Wanneer moet u ze allemaal gebruiken?

TDD past goed wanneer:

• U schrijft complexe logica, zoals prijzen, parseren of machtigingen.
• Je repareert een bug, omdat je deze eerst kunt reproduceren met een mislukte test.
• Je werkt aan code die vaak zal veranderen.

BDD past goed wanneer:

• Bedrijfsregels zijn complex en misverstanden zijn duur.
• Niet-technische mensen zullen de scenario’s echt lezen en bespreken.
• Verschillende teams hebben behoefte aan een gedeelde definitie van hoe iets zich gedraagt.

Het kan overdreven zijn als je: een wegwerpprototype schrijft of een onduidelijk technisch idee onderzoekt. Veel ontwikkelaars pieken eerst en herschrijven vervolgens met tests. BDD-tooling is ook een slechte investering als niemand buiten de engineering ooit naar de scenario’s zal kijken. In dat geval zijn eenvoudige tests met goede namen eenvoudiger.

Veel voorkomende fouten

• BDD behandelen als een testtool. Komkommer zonder samenwerking is slechts een uitgebreide manier om tests te schrijven.
• Implementatie testen in TDD. Tests die verband houden met privégegevens breken tijdens elke refactor.
• De refactorstap wordt overgeslagen. Je slaagt voor tests naast rommelige code.
• Tests achter de code schrijven en deze TDD noemen. Dat is nog steeds nuttig, maar je verliest de ontwerpfeedback.
• Te veel UI-scenario’s schrijven. Deze worden traag en onstabiel. Zie flaky-tests.
• Op jacht naar dekkingscijfers. Goede berichtgeving mist nog steeds gedrag waar niemand rekening mee heeft gehouden, zoals uit ons voorbeeld blijkt.

Tot slot

TDD helpt je om het juiste te bouwen, en BDD helpt je om het juiste te bouwen. Ons kortingsvoorbeeld liet beide kanten zien: de code doorstond alle tests, maar een eenvoudig gesprek bracht een verkeerde veronderstelling aan het licht. Probeer het op uw volgende kleine functie. Schrijf samen met een collega drie concrete voorbeelden vóór elke code, en bouw deze vervolgens één mislukte test tegelijk.

Veelgestelde vragen

Blijf leren