BDD: cos'è, scenari di comportamento e framework

Cos'è il BDD?

Behavior-Driven Development è un'evoluzione del TDD proposta da Dan North nel 2006 come risposta al problema della formulazione dei test. Nel TDD, lo sviluppatore scrive un test, ma la domanda “cosa testare esattamente?” rimane aperta. Il BDD risolve questo problema spostando l'attenzione dal test del codice alla descrizione del comportamento del sistema dal punto di vista dell'utente.

L'innovazione chiave del BDD è un linguaggio comune per tutti i partecipanti al progetto. Sviluppatori, tester, analisti e clienti discutono degli scenari in un linguaggio unificato che funge simultaneamente da test eseguibile. Questo elimina il classico problema del “telefono senza fili” in cui i requisiti perdono significato nel passaggio dall'analista allo sviluppatore.

Storia del BDD

Dan North formulò il BDD nel 2006 nel suo articolo “Introducing BDD” sul blog ThinkCode. Notò che i nomi dei test nel TDD sono spesso formulati in termini di implementazione (“testAddUser”) piuttosto che in termini di comportamento (“l'utente dovrebbe potersi registrare con email”). Il BDD ha sostituito la parola “test” con “should” e “assert” con “expect”, spostando l'attenzione sul valore per l'utente.

Il BDD come pratica di comunicazione

Secondo uno studio dell'Università di Cambridge (2021), i progetti che utilizzano scenari BDD nella comunicazione con il cliente riducono gli errori nei requisiti del 35% rispetto alle specifiche tradizionali in documenti di testo. Gli scenari eseguibili non consentono formulazioni ambigue — ogni Given-When-Then o viene superato o fallisce.

Linguaggio Gherkin e sintassi

Gherkin è un linguaggio specifico del dominio utilizzato dai framework Cucumber e SpecFlow per descrivere scenari di comportamento. Gherkin utilizza indentazione e parole chiave per strutturare gli scenari, rimanendo leggibile per persone senza background tecnico.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Parole chiave di Gherkin

Gherkin definisce diverse parole chiave di base. Feature descrive la funzionalità, Scenario descrive uno scenario specifico, Given descrive le precondizioni, When descrive l'azione, Then descrive il risultato atteso. Inoltre, And e But sono utilizzati per combinare più condizioni.

Struttura del file .feature

I file Gherkin hanno estensione .feature e sono memorizzati nella directory src/test/resources/features/ nei progetti Android. Ogni file inizia con una descrizione di Feature, seguita da uno o più Scenari. Per la parametrizzazione si utilizza Scenario Outline con tabelle Examples — questo consente di eseguire lo stesso scenario con dati diversi.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Formato Given-When-Then

Given-When-Then è un pattern strutturale per descrivere scenari, adottato dal BDD dal domain-driven design. Ogni scenario è composto da tre parti: precondizioni, azione e risultato atteso. Questo formato corrisponde naturalmente ad Arrange-Act-Assert dei test unitari ma utilizza un linguaggio adatto al business.

Given: contesto

Il blocco Given descrive lo stato del sistema prima dell'inizio dello scenario: quali dati esistono, quali componenti sono attivi, in quale modalità opera l'applicazione. Nel contesto mobile, può essere “l'utente ha effettuato l'accesso”, “il carrello non è vuoto” o “il dispositivo è in modalità offline”.

When: azione

Il blocco When descrive un evento innescato dall'utente o dal sistema: pressione di un pulsante, ricezione di una notifica push, risposta del server. Nelle applicazioni mobili, ciò corrisponde spesso alla chiamata di un metodo del ViewModel o al clic su un elemento dell'interfaccia.

Then: risultato

Il blocco Then descrive il cambiamento di stato atteso: cambio schermata, chiamata API, aggiornamento del database. I controlli in Then devono essere misurabili e inequivocabili — diventano asserzioni nel codice eseguibile.

BDD e TDD: confronto degli approcci

BDD e TDD sono spesso confusi, sebbene siano diversi livelli di disciplina. Il TDD è una tecnica di progettazione a livello di codice: “come scrivere l'implementazione”. Il BDD è una tecnica di specifica a livello di requisiti: “cosa deve fare il sistema”.

Complementarità nel progetto

I migliori progetti mobili utilizzano il TDD a livello di singole classi (livello dominio) e il BDD a livello di scenari (livello funzionalità). Questo fornisce una doppia copertura: il TDD garantisce la correttezza dell'implementazione, il BDD garantisce la correttezza della comprensione dei requisiti. Google nella sua pratica interna utilizza una combinazione di TDD e BDD per le applicazioni Android, come indicato nella documentazione Android Testing (2024).

Strumenti BDD per lo sviluppo mobile

L'ecosistema BDD include framework per tutte le piattaforme e linguaggi di sviluppo mobile più popolari. La scelta dello strumento dipende dallo stack tecnologico e dal livello di automazione.

Cucumber per Android

Cucumber è il framework BDD più popolare, che lavora con scenari Gherkin. Per i progetti Android si utilizza la libreria io.cucumber:cucumber-android, che si integra con gli strumenti di test dell'interfaccia Espresso e Compose Test. Cucumber supporta Kotlin e Java, rendendolo una scelta universale per gli studi che utilizzano entrambi i linguaggi.

SpecFlow per Xamarin

SpecFlow è un framework BDD per l'ecosistema .NET, utilizzato in progetti Xamarin.Forms e .NET MAUI. SpecFlow si integra con NUnit e xUnit, e le sue step definitions sono scritte in C#. Per i progetti mobili, SpecFlow consente di riutilizzare gli scenari tra le versioni Android e iOS dell'applicazione su una base di codice condivisa.

Quick/Nimble per iOS

Per lo sviluppo iOS in Swift, esistono i framework BDD Quick e Nimble. Quick fornisce un DSL per descrivere scenari in stile describe/it, e Nimble fornisce matchers con sintassi leggibile. Sebbene questi framework non utilizzino Gherkin direttamente, implementano il principio BDD: descrivere il comportamento in un linguaggio comprensibile per l'intero team.

Esempi di scenari BDD e codice

Consideriamo un esempio completo di BDD in un progetto Android: uno scenario di checkout dell'ordine. Prima scriviamo uno scenario Gherkin, poi le step definitions in Kotlin.

Principio di funzionamento del BDD: three amigos

La metodologia BDD si basa sull'incontro dei three amigos — tre ruoli: sviluppatore, tester e analista. Scrivono insieme gli scenari prima dell'inizio dello sviluppo, fissando una comprensione comune dei requisiti. Se uno dei tre partecipanti non capisce lo scenario, significa che il requisito è formulato in modo ambiguo. Questa pratica è descritta nel libro “Discovery: Explore Behaviour Using Examples” (Gáspár & North, 2021) ed è una parte obbligatoria del processo BDD nei team maturi.

Scenario Gherkin di checkout dell'ordine

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions in Kotlin

Le step definitions sono codice che collega gli scenari Gherkin con l'implementazione del test. Ogni passo è un metodo con un'annotazione corrispondente a una parola chiave di Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Integrazione con Cucumber Android

Per eseguire test BDD in un progetto Android, si utilizza CucumberAndroidJUnitRunner. Scansiona i file .feature nelle risorse, trova le step definitions corrispondenti tramite espressioni regolari ed esegue gli scenari come normali test strumentati. I risultati sono formattati in un report HTML comprensibile per il cliente.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Sfide nell'implementazione del BDD nei progetti mobili

L'implementazione del BDD nello sviluppo mobile comporta diverse difficoltà pratiche. La comprensione di questi problemi aiuta i team a evitare frustrazioni e costruire un processo BDD sostenibile.

Manutenzione dei file .feature

Il problema principale è la desincronizzazione tra scenari Gherkin e codice di produzione. Se gli sviluppatori modificano le API senza aggiornare le step definitions, i file .feature non corrispondono più all'implementazione. La soluzione è eseguire i test BDD nella pipeline CI/CD e richiedere lo stato verde per le merge request. La pratica del “BDD as a gating mechanism” è descritta nella documentazione di Cucumber (2024) ed è uno standard del settore.

Prestazioni dei test BDD

Gli scenari BDD in Cucumber vengono eseguiti come test strumentati su un dispositivo Android o emulatore. Questo è da 10 a 50 volte più lento dei normali test unitari sulla JVM. Un singolo test di accettazione può richiedere 20–30 minuti per una grande applicazione Android. Si consiglia di eseguire i test BDD in un job CI separato di notte, mentre i test unitari vengono eseguiti a ogni push. Questa strategia bilancia la velocità di feedback e la copertura degli scenari.

Formazione del team su Gherkin

La transizione al BDD richiede formazione non solo degli sviluppatori ma anche di analisti e tester. Gherkin è un linguaggio semplice, ma scrivere buoni scenari richiede pratica. Errori tipici dei principianti: scenari troppo lunghi (più di 10 passi), mescolare Given-When-Then, usare termini tecnici in scenari di business. Secondo BDD Academy (2024), i team necessitano in media di 4–6 sprint per raggiungere la maturità nella scrittura di scenari BDD.