Behavior-driven development: di cosa si tratta?

In passato la gestione della qualità impiegava settimane a controllare la funzionalità di un software completamente sviluppato. Oggi, grazie ai test automatici, è possibile scoprire con la semplice pressione di un pulsante se un’applicazione complessa svolge i propri compiti senza problemi.

Una tecnica sempre più diffusa è il behavior-driven development (sviluppo guidato dal comportamento), abbreviato in BDD. Questa forma di sviluppo software agile ha avuto origine dal test-driven development (TDD) ed è considerata la sua estensione logica. Contrariamente al TDD, in BDD il rispettivo software è considerato principalmente dal punto di vista dell’utente. Tale approccio promuove una progettazione più olistica del software e facilita la collaborazione tra sviluppatori, responsabili della qualità e clienti.

Con la crescente complessità delle applicazioni software, stanno emergendo sempre più metodi di gestione della qualità e dei test. Solo così è possibile controllare in modo affidabile la funzionalità dei singoli componenti e individuare subito i difetti. Lo sviluppo guidato dai test o test-driven development (TDD) è noto da tempo. In tale contesto gli sviluppatori creano, parallelamente al software, dei test unitari o test di sistema appropriati. Nel processo di progettazione di un software, tuttavia, ha senso coinvolgere non solo i programmatori ma anche i membri del team o le parti interessate privi di conoscenza tecnica del codice. Il behavior-driven development (BDD) permette proprio questo.

Con lo sviluppo software agile, tutti i partecipanti al progetto possono definire il comportamento desiderato dell’applicazione prima che il programmatore crei il testo sorgente. Questo accade sulla base di descrizioni redatte in un linguaggio facilmente comprensibile per le persone. Ciò significa che anche il cliente, per il quale viene sviluppato il software, assume una parte più attiva nella modellazione. BDD promuove quindi la collaborazione e assicura una redistribuzione della responsabilità. Utilizzando correttamente questo tipo di sviluppo software, evitate fin dall’inizio incomprensioni e generate idealmente un prodotto finale di qualità superiore.

Come suggerisce il nome, il behavior-driven development si basa sul comportamento che il rispettivo software dovrebbe mostrare. Grazie al cosiddetto linguaggio ubiquo, ovvero al “linguaggio comunemente usato”, anche i dilettanti possono creare determinate descrizioni comportamentali. Il linguaggio ubiquo deriva dal domain-driven design (DDD), che, come il BDD, si concentra sul dominio dell’applicazione. Entrambi gli approcci tengono conto di tutte le aree coinvolte nella creazione del software e le combinano indipendentemente da framework, linguaggi di programmazione o strumenti. L’uso di un linguaggio uniforme consente proprio questo.

Nonostante tutto anche il behavior-driven development richiede strumenti e framework. Affinché i casi di test definiti possano anche essere tradotti in un codice eseguibile, è necessario seguire alcune regole. Ad esempio, le descrizioni nel BDD non sono scritte in testo libero. Utilizzando strumenti BDD come JBehave, Cucumber o Behat si segue una struttura definita che consente un’implementazione corretta. L’uso di questi strumenti è molto più semplice dell’apprendimento di un linguaggio di programmazione classico. Ecco la struttura gerarchica che seguite normalmente nel behavior-driven development:

• Eseguite innanzitutto un’analisi dei requisiti in cui definite esattamente i compiti, gli obiettivi e le funzionalità del software. Quindi chiedete a voi stessi o al vostro cliente cosa dovrebbe fare il software.
• Dopo avere identificato tutte le funzionalità, queste vengono descritte sotto forma di scenari predefiniti. Provate a pensare a tutte le possibili situazioni in cui il software dovrebbe rispondere con una risposta specifica.
• Nel passaggio successivo registrate la risposta prevista per ogni scenario nello schema “Assume-If-Then”. “Supposto” descrive il software prima del test, “Se” l’azione durante il test e “Allora” lo stato del software dopo il test.

Il vocabolario può variare leggermente a seconda dello strumento BDD in uso. Invece di “Supposto” alcuni strumenti accettano anche formulazioni come “Dato”. Per inciso, tali strumenti sono disponibili per i linguaggi di programmazione più comuni come Java, JavaScript, Python o Ruby.

Immaginate di voler sviluppare un negozio online intuitivo. Una volta che il cliente si è registrato nel vostro negozio, i suoi dati utente devono essere salvati. Così potrà accedere più volte senza dover inserire nuovamente i suoi dati personali. Nel linguaggio Gherkin ampiamente usato, che viene utilizzato nello strumento BDD Cucumber, la sintassi corretta è la seguente:

L’esempio sopra mostra che utilizzando l’aggiunta “E” è possibile impostare diverse condizioni e quindi rendere più complessi i casi di test.

Nel testare un software il behavior-driven development si occupa della domanda “Come“. Le parti interessate vogliono sapere come testare correttamente il comportamento di un codice e non la sua implementazione. Il cosiddetto test del modulo, invece, riguarda la corretta implementazione di una singola unità di codice. Questo metodo di prova riguarda quindi il “Cosa” ed è un buon modo per trovare singoli bug. Il Test Driven Development, che si occupa del processo di esecuzione dei test, risponde alla domanda del “Se”. Questo processo può includere anche test di moduli o altri metodi di test.

La seguente tabella riassume brevemente i vantaggi e gli svantaggi del behavior-driven development:

Sebbene sia possibile utilizzare ogni metodo di prova singolarmente, la qualità del software migliorerà considerevolmente se si utilizzano più metodi di prova in combinazione. Con BDD si definisce la procedura migliore per scrivere i test, mentre con TDD si assicura un'elevata copertura dei test.