• chi vuole qualcosa
• chi lo sa fare

Ma perché focalizzarsi sui requisiti? E’ così importante? Vediamo.

Anche all’interno dello sviluppo basato su metodologie agili non si è al riparo da problemi, errori, anomalie: backlog di 4+ anni, debito tecnico, incomprensione sullo scope e sui deliverable, mancanza di specifiche, numero eccessivo di test postumi allo sviluppo.

Quello che manca è un’attenzione specifica al comportamento (Behaviour!) del sistema: cioè ai suoi requisiti.

BDD è appunto un framework che si focalizza sulla definizione dei requisiti, ma in modo agile, cioè requisiti che cambieranno nel tempo e si adatteranno facilmente e velocemente ai nostri incrementi di prodotto!
E i test? I test sono un side effect, esattamente come il TDD è una tecnica di design e i test sono “solo” un sottoprodotto dell’attività di design. In BDD il requisito diventa un Acceptance Criteria scritto in modo formale. 

BDD si basa su tre principi:

1. Business Value
2. Tutto è un comportamento (requisiti funzionali e non funzionali: everything is a behaviour)
3. Enough is enough (fondamentale!)

e richiede che si lavori per iteration di prodotto: è fondamentale poter “affettare” il prodotto in deliverable distinti, che approfondiscono ed espandono il sistema iterazione dopo iterazione.

BDD ha molti formalismi, tra cui i più diffusi sono Spec e Gherkin.

Per calarci nel vivo della pratica, abbiamo ipotizzato di realizzare un diario alimentare, descritto secondo la tecnica dello User Story Mapping (dai uno sguardo alla sintesi di un nostro incontro sul tema).

Per realizzare il diario abbiamo previsto tre iterazioni (MVP 1, 2, 3). Possediamo già una definizione di enough: dobbiamo fermarci alla realizzazione delle User Stories dell’iterazione “MVP 1”: 1) Pagina di inserimento pasti; 2) Tabella pasti inseriti. Per cui nell’espressione dei requisiti (ovvero: comportamenti, acceptance criteria) in un linguaggio formale (Gherkin!) dobbiamo limitarci a questi due comportamenti, senza andare oltre.

Prima dell’esempio, specifichiamo a quale livello di comportamento stiamo operando. Ci sono infatti diverse profondità a cui si può arrivare a determinare il comportamento. Questo schema dovrebbe chiarire quante e quali sono. 

Nell’esempio parleremo solo di User Behaviour. Cominciamo! Affrontiamo il primo requisito espresso dalla user story “Inserimento nuovo pasto”. Nella formalizzazione BDD (useremo Gherkin) diventerà la funzionalità.

Alla funzionalità potremo associare una descrizione. Dopodiché espliciteremo gli scenari. Ciascuno scenario rappresenta compone un acceptance test scandito dagli step: given, when,  then:

• Dato un determinato fatto/contesto (given)
• Al verificarsi un determinato evento/azione (when)
• Deve succedere che (then)

Given: rappresenta gli step necessari affinché il sistema raggiunga lo status corretto per la verifica del test;

When: l’evento che deve avvenire per mezzo dell’utente per azionare la funzionalità in esame; è sempre un evento, si tratta di un’azione;

Then: descrive cosa avviene nel sistema e quali sono le reazioni apprezzabili da parte dell’applicazione;

Lo step che guida la costruzione dello scenario è il “then”, perché rappresenta il Business Value (uno dei tre principi del BDD) associato al requisito: è il perché del requisito, il suo valore, il suo scopo.

Non ci stupirà quindi leggere quindi una specifica del genere:

Funzionalità: Inserimento nuovo pasto

Descrizione:

come «persona a dieta»
voglio una pagina di inserimento del nuovo pasto
per poter inserire un nuovo pasto al diario alimentare

Scenario: Apertura pagina inserimento dati

data la pagina contenente la lista dei pasti
dato il pulsante «nuovo pasto»
quando il pulsante «nuovo pasto» viene cliccato
allora la modale di inserimento pasto viene mostrata

Scenario: Definizione di un pasto

data la modale di inserimento pasto
allora conterrà la lista degli alimenti
e conterrà il tipo di pasto

Scenario: Tipo di pasto

allora potrà essere colazione, pranzo o cena

Questo tipo di descrizione formale produce un vocabolario accurato, accessibile, descrittivo e consistente, tale da rendere comprensibile il sistema a tecnici e non tecnici. E’ quello che nel Domain-Driven Design viene chiamato ubiquitous language.

Per concludere, se dovessi sintetizzare il BDD dire che è uno sforzo congiunto di catturare il valore attraverso le “parole giuste” in una conversazione tra tutti gli attori, focalizzato sullo scambio continuo tra i diversi membri del team.

Qui le slide proiettate durante l’incontro

Foto del meetup:

Paolo Manca

More Posts

L'articolo BDD – molto più che testing proviene da Agile Community Torino.