Il dibattito TDD vs BDD viene spesso inquadrato come la scelta di una parte. In realtà, rispondono a domande diverse. Lo sviluppo basato sui test chiede se il codice fa ciò che lo sviluppatore intendeva, mentre lo sviluppo basato sul comportamento chiede se il team è d’accordo su cosa dovrebbe fare il software.

Per rendere concreta la differenza, creiamo una piccola funzione di sconto con ogni approccio. Abbiamo eseguito il codice su Python 3.13, utilizzando la libreria standard, e i risultati seguenti provengono da quell’esecuzione. La parte BDD utilizza un nostro piccolo runner per mostrare il meccanismo, quindi un progetto reale utilizzerebbe uno strumento come Cucumber o si comporterebbe invece.

La risposta breve

Lo sviluppo basato sui test (TDD) è una pratica di codifica. Scrivi un piccolo test fallito, fallo passare con il codice più semplice e poi migliori il design. I test sono scritti in codice e principalmente dagli sviluppatori. Kent Beck ha reso popolare la pratica.

Lo sviluppo guidato dal comportamento (BDD) è una pratica di collaborazione nata dal TDD e Dan North ha introdotto il termine. Sviluppatori, tester e uomini d’affari concordano su esempi di come dovrebbe comportarsi il sistema, scritti in un linguaggio semplice, e tali esempi possono quindi essere automatizzati.

TDD e BDD fianco a fianco

La caratteristica

Ecco la regola aziendale che implementeremo: Gli ordini di 1.000 o più ricevono uno sconto del 10%. I membri ricevono uno sconto extra del 5% su questi ordini.

Può sembrare chiaro, ma è già ambiguo. Un membro che spende 500 ottiene uno sconto del 5%? La frase dice “quegli ordini”, quindi presumiamo di no. Tienilo a mente, perché questo è esattamente il tipo di domanda che BDD è progettato per far emergere presto.

Costruirlo con TDD

TDD segue un breve ciclo noto come red, green, refactor:

Questi sono i nostri test, con uno per ogni regola:

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)

Abbiamo quindi scritto il codice in tre fasi, eseguendo i test dopo ciascuna. Una sessione TDD rigorosa aggiunge un test alla volta e mostra la stessa progressione:

Fase 1: la cosa più semplice

def discount(total, is_member):
    return 0

# 3 tests, 2 failed
#   test_member_gets_extra_five_percent
#   test_ten_percent_from_1000

Restituire zero sembra sciocco, ma dimostra che i test possono effettivamente fallire e l’unico test che supera è la regola “nessuno sconto”.

Fase 2: aggiungere la soglia

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: aggiungi membri e ripulisci

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

Passano tutti e tre. Ma leggi attentamente questa versione. Offre a un membro che spende 500 uno sconto del 5%, che non è ciò che pensavamo significasse la regola. Nessun test ha coperto quel caso, quindi niente lo ha segnalato. TDD protegge solo il comportamento che pensavi di testare. Questa è una vera limitazione, ed è il motivo per cui le conversazioni sugli esempi sono così importanti.

Perché il ciclo è importante

• Il rosso dimostra che il test funziona. Un test che non ha mai fallito potrebbe non testare nulla.
• Il verde ti mantiene concentrato. Scrivi solo il codice necessario, il che aiuta a prevenire un’ingegneria eccessiva.
• Refactor mantiene elevata la qualità. I test ti danno la sicurezza necessaria per modificare il progetto in modo sicuro.
• Influenza il design. Il codice difficile da testare è spesso troppo strettamente accoppiato e lo noti subito.

Il nostro tutorial pytest mostra un modo più conveniente per scrivere test come questi e l’analisi dei valori limite spiega perché abbiamo scelto 999 e 1000 come valori.

Costruirlo con BDD

BDD inizia con una conversazione, non con gli strumenti. Spesso si tratta di un breve incontro noto come i tre amigos, con un addetto al prodotto, uno sviluppatore e un tester che discutono esempi concreti:

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.

Quell’unico scambio avrebbe rilevato il problema nel nostro codice TDD. Quindi registrano i loro esempi in un formato strutturato chiamato 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

Chiunque nel team può leggerlo e dire “sì, è giusto” o “no, è sbagliato”. Anche se non lo automatizzi mai, lo scenario ha già svolto un lavoro utile.

Collegamento dei passaggi al codice

Gli strumenti collegano ciascuna riga in linguaggio semplice a una funzione, chiamata definizione del passaggio. Per mostrare l’idea, abbiamo scritto noi stessi una piccola versione ed eseguito il primo scenario:

@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

Gli strumenti reali aggiungono parametri, in modo che un singolo passaggio possa corrispondere sia a “1000” che a “500”, oltre al reporting. Il risultato è una documentazione vivente: una semplice descrizione del sistema che fallisce clamorosamente se smette di essere vera.

Scrivere buoni scenari

Gli scenari che descrivono clic e ID campo si interrompono a ogni riprogettazione e i lettori aziendali smettono di leggerli. Conserva i dettagli dell’interfaccia utente nel codice del passaggio. Questi scenari sono cugini stretti degli esempi in caso di test vs scenario di test e sono spesso utilizzati anche nei test di accettazione dell’utente.

Usandoli entrambi insieme

I due si inseriscono naturalmente in un flusso di lavoro “outside-in”:

1. Il team concorda sul comportamento e scrive uno scenario BDD. Fallisce, perché non esiste ancora nulla.
2. Uno sviluppatore utilizza TDD per costruire le piccole unità necessarie.
3. I test unitari vengono superati e, alla fine, anche lo scenario.
4. Tutto viene eseguito nella tua pipeline CI/CD.

Mantieni ciascuno al giusto livello. Dovresti avere alcuni scenari per comportamenti importanti e molti test unitari veloci per i dettagli. La nostra guida ai test unitari e di integrazione copre l’equilibrio.

Strumenti

Quando utilizzarli ciascuno

Il TDD si adatta bene quando:

• Stai scrivendo una logica complessa, come prezzi, analisi o autorizzazioni.
• Stai correggendo un bug, poiché puoi riprodurlo prima con un test fallito.
• Stai lavorando su un codice che cambierà spesso.

BDD si adatta bene quando:

• Le regole aziendali sono complesse e le incomprensioni sono costose.
• Le persone non tecniche leggeranno e discuteranno davvero gli scenari.
• Diversi team necessitano di una definizione condivisa di come si comporta qualcosa.

Potrebbero essere eccessivi quando: stai scrivendo un prototipo usa e getta o esplorando un’idea tecnica poco chiara. Molti sviluppatori prima effettuano il picco, poi riscrivono con i test. Anche gli strumenti BDD sono uno scarso investimento se nessuno al di fuori dell’ingegneria esamina mai gli scenari. In tal caso, i test semplici con nomi validi sono più semplici.

Errori comuni

• Trattare BDD come strumento di test. Il cetriolo senza collaborazione è solo un modo dettagliato per scrivere test.
• Implementazione del test in TDD. I test legati ai dettagli privati ​​si interrompono durante ogni refactoring.
• Saltando il passaggio del refactoring. Puoi superare i test anche se il codice è disordinato.
• Scrivere test dopo il codice e chiamarlo TDD. È comunque utile, ma si perde il feedback sulla progettazione.
• Scrivere troppi scenari dell’interfaccia utente. Questi diventano lenti e instabili. Vedi test instabili.
• Alla ricerca di numeri di copertura. Una buona copertura non tiene ancora conto di comportamenti che nessuno ha preso in considerazione, come mostra il nostro esempio.

Considerazioni finali

TDD ti aiuta a costruire la cosa giusta e BDD ti aiuta a costruire la cosa giusta. Il nostro esempio di sconto ha mostrato entrambi i lati: il codice ha superato tutti i test, ma una semplice conversazione ha rivelato un presupposto sbagliato. Provalo sul tuo prossimo piccolo servizio. Scrivi tre esempi concreti con un collega prima di qualsiasi codice, quindi costruiscilo un test fallito alla volta.

Domande frequenti

Continua a imparare