Behavior-Driven Development (BDD)

Il Behavior-Driven Development (BDD, sviluppo guidato dal comportamento) è un modo per costruire una comprensione condivisa prima di scrivere il codice. Product, sviluppo e testing (spesso chiamati i “three amigos”) discutono una funzionalità attraverso esempi concreti di come deve comportarsi. Quegli esempi diventano i criteri di accettazione, e molti team li automatizzano poi come specifiche eseguibili con strumenti come Cucumber, Reqnroll (il successore di SpecFlow) o Behave.

Esempio

Una conversazione su una regola di sconto si trasforma in esempi come questi:

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

Il secondo scenario è quello prezioso. Scriverlo costringe a porsi la domanda “oltre 100, o da 100 in su?” prima che qualcuno costruisca la cosa sbagliata.

Le tre pratiche

1. Discovery. Esplorare la funzionalità con esempi, trovare casi limite e domande aperte.
2. Formulation. Scrivere gli esempi concordati in una forma strutturata e leggibile dal business, di solito Gherkin.
3. Automation. Collegare ogni step al codice, così che gli esempi vengano eseguiti come test e facciano da documentazione vivente.

Errori comuni

• Trattare il BDD come uno strumento di test. Scrivere Gherkin dopo il codice, da soli, senza alcuna conversazione, ti dà il costo di un livello di traduzione senza il beneficio della comprensione condivisa.
• Step a livello di UI. “When I click the button with id submit” descrive l’interfaccia, non il comportamento. Gli step dovrebbero sopravvivere a un redesign.
• Automatizzare ogni scenario tramite il browser. Una regola di business come lo sconto qui sopra è di solito più veloce e affidabile da automatizzare contro un’API o un livello di servizio.
• Librerie di step enormi. Centinaia di step definition leggermente diverse sono difficili da mantenere. Mantieni il vocabolario ridotto e focalizzato sul dominio.

Il BDD funziona bene quando le persone del business leggono davvero gli scenari e vi contribuiscono. Quando nessuno al di fuori dell’ingegneria li guarda, del semplice codice di test con buoni nomi è spesso più semplice.