Condividi l'articolo

Ott 28, 2019 | Agile, BDD, Test Management | 0 commenti

Introduzione a Gherking, la lingua di BDD per la scrittura dei requisiti di business

Agile, BDD, Test Management | 0 commenti

Scritto da Sergio Scorsoglio

Tempo di lettura: 15 min ca

Introduzione a Gherking

Di solito, i requisiti di business sono troppo di alto livello per essere utilizzati (e spesso compresi) dagli sviluppatori per scrivere direttamente il software. Vanno quindi ridefiniti ad un livello comprensibile a tutti e sufficientemente dettagliato per consentirne la traduzione in un linguaggio di programmazione.

Le tecniche di sviluppo Agile aumentano e migliorano la comunicazione tra i componenti di un team. Tra queste tecniche, lo sviluppo guidato dal comportamento o BDD (Behaviour-driven development) si pone come obiettivo la trasformazione in modo semplice del requisito in codice funzionante e verificato a patto che il requisito sia sufficientemente specifico da essere compreso da tutti. Per fare questo è necessario che il requisito sia scritto con una modalità intellegibile, ovvero che uomini di business, analisti, sviluppatori e tester comprendano nel medesimo modo.

Gherkin è un linguaggio usato per descrivere in modo strutturato specifiche di business di un processo utilizzando il linguaggio naturale. La sua caratteristica è di utilizzare il dominio linguistico specifico del processo che sta descrivendo. Serve dunque per descrivere nel dettaglio le funzionalità del processo che stiamo implementando utilizzando un linguaggio comprensibile a tutti coloro che stanno partecipando alla sua implementazione.

Per scrivere in linguaggio Gherkin è sufficiente scrivere un file di testo con estensione “.feature” e la seguente struttura:

Attenzione però, lo dovrai scrivere in inglese (almeno per il momento …):

La struttura di Gherkin può essere anche più complessa di così, ma per le cose complicate c’è sempre tempo ;-).
Il file Gherkin nella sostanza descrive una feature, o più semplicemente una funzionalità, proprio come fa una user story. Inizia sempre con la keyword Feature seguita dalla descrizione macroscopica in linguaggio naturale della funzionalità che vogliamo realizzare.
La pratica BDD prevede che la feature sia il prodotto di una discussione a cui partecipano le persone chiave coinvolte nella sua realizzazione. I ruoli necessari per scrivere una buona feature sono: l’esperto di dominio/business che conosce la funzione da realizzare, l’analista che aiuti quest’ultimo a tradurla in una storia da inserire nella feature, ed il tester che aiuti a definire i criteri di accettazione determinando quali scenari sono più o meno utili nella descrizione della feature. Infine un tecnico quantifica l’impegno necessario a realizzarla ed eventualmente propone approcci alternativi.
Un primo risultato è la semplicità con cui emerge in modo chiaro quali sono gli scenari di valore, quali sono i casi limite di questi scenari e tra questi quali sono poco probabili, aiutando così il PO a definire le priorità di progetto.
In caso non fosse possibile ultimare la redazione della feature per mancanza di informazioni o conoscenza della funzionalità si dovrà procedere con delle esplorazioni di approfondimento (spike).
Quando il gruppo di lavoro si riunisce per discutere la feature, in genere emergono dei dettagli che la caratterizzano, che si possono raccogliere ed annotare al suo interno.

Come avrai certamente notato, ad ogni feature (funzionalità) possono essere associati più scenari d’uso (casi d’uso) che la descrivono più in dettaglio.
In Gherkin lo scenario è caratterizzato da:
– un contesto o precondizione (Given)
– una azione (When)
– un risultato e quindi una asserzione su di esso (Then)
In altre parole lo scenario descrive una particolare istanza della feature in cui viene messo in evidenza che la funzionalità ha un proprio stato di partenza (Given) a cui segue una azione (When) che determina un risultato (Then).
Es:
Dato che sono in questo particolare stato, quando compio questa azione, allora mi aspetto questo risultato.
Dato che il mio CC ha un saldo sufficente e nella giornata odierna non ho fatto altri prelievi ATM (Given), faccio un prelievo di 100 euro (When) , ed ottengo il contante dal bancomat (Then).
Si dice dunque che il pattern di uno scenario Gherkin è context, action, outcome.
Il Gherkin è anche un linguaggio Whitespace oriented (nulla di complicato, se vuoi approfondire vedi https://en.wikipedia.org/wiki/Whitespace_(programming_language)). In pratica, attraverso l’identificazione di alcune parole chiave (Feature, Scenario …) riconosce i blocchi della struttura e, all’interno del blocco, utilizza il fine riga (a capo) per definire uno step (o statement)

Vediamo un po’ di keywords e sintassi.
Feature: descrizione in linguaggio naturale della specifica di business (il cosa dobbiamo fare)
Scenario: esempio rappresentativo di come funzionerà la specifica di business (un caso d’uso, un cosa più specifico)
Given, When, Then, And, But: step utilizzati per descrivere gli scenari (finalmente il come lo dobbiamo fare)
Background: descrive un contesto (Given) comune a tutti i nostri scenari. Si applica alle feature che hanno più di uno scenario ed in cui tutti gli scenari condividono il contesto (passi propedeutici per l’azione) ed evita che ci sia una ridondante ripetizione della descrizione del medesimo contesto in ogni scenario.
Funziona come il setup dei juni test.

Scenario Outline: si utilizza per evitare la duplicazione di scenari simili in cui le uniche differenze sono I dati di input ed output in essi contenuti. Si scrive un unico scenario che contiene una sezione “Examples” in cui è presente una rappresentazione tabellare dei dati di input ed output che possono essere utilizzati all’interno degli step che descrivono lo scenario.
Scenario standard:

Scenario Outline:

Nota l’utilizzo dei caratteri “<” e “>” per racchiudere i parametric che dovranno essere sostituiti con i dati presenti nella tabella “Examples”.

Caratteri speciali:
# precede una riga di commento
| usato per definire i data tables, strutture tabellari contenenti dati utilizzabili negli scenari
@ usato per creare i tag

Per organizzare le specifiche di business in modo logico, isolare e quindi identificare gruppi di feature e/o scenari, è sufficiente utilizzare i tags. Il tag è una etichetta (parola) preceduta dal carattere @ che applicheremo a tutte le feature o tutti gli scenari che vogliamo raggruppare. E’ possibile inserire più di un tag alla volta separandoli con il carattere spazio.

I tag posizionati sopra una Feature saranno ereditati da Scenario, Scenario Outline e Examples. I tag posizionati sopra uno Scenario Outline verranno ereditati dagli Examples.

All’interno dello scenario possono essere utilizzate delle tabelle che consentono di specificare dati strutturati che aiutano a spiegare in modo più preciso il dominio di dati utilizzato dalla feature.

Quello che è emerso fino ad ora è che Gherkin è un “Business Readable, Domine Specific Language” che attraverso la sua impostazione ci consente di documentare il progetto in modo semplice (in fondo stiamo parlando di un file di testo), strutturato e comprensibile a tutti gli addetti ai lavori.
Descrive le specifiche di business in linguaggio naturale attraverso la spiegazione di che cosa deve fare la funzionalità in esame spiegata con esempi che riportano l’input che sollecita la funzionalità ed il relativo output prodotto.
Ora che abbiamo capito (o almeno lo spero) a cosa serve e come scrivere una semplice feature in linguaggio Gherkin, ti voglio svelare un altro suo importante utilizzo: il file Gherkin può essere parte integrante della pipeline di sviluppo e venire utilizzato come file descriptor per l’esecuzione automatica dei test. Stiamo quindi affermando che la documentazione di progetto, oltre ad essere accessibile e condivisa da tutti gli stakeholder, non è solo più carta ma è anche utilizzata dai sistemi software che implementano la pipeline di CI/CD per automatizzare le verifiche qualitative del software.
Se non ho ancora catturato la tua attenzione, allora ci possiamo salutare qui. Diversamente nel seguito di questo articolo vedremo ancora alcune indicazioni per scrivere delle feature efficaci mettendo così le basi per introdurre il linguaggio Gherkin in un progetto di sviluppo e più in generale in una pipeline di CI/CD.
Bene, stai proseguendo con la lettura. Per prima cosa abbiamo la necessità di allargare i nostri  orizzonti sul linguaggio Gherkin per poterlo utilizzare all’interno delle pipeline di sviluppo.
Iniziamo con condividere alcune buone regole per scivere le specifiche di business del nostro progetto.

Considerazioni generali:

  • ogni feature che scriveremo dovrà essere indipendente dalle altre (ogni feature deve poter essere eseguita da sola senza mutare il risultato)
  • gli scenari contenuti in una feature dovranno essere tra loro indipendenti (ogni scenario deve poter essere eseguito da solo senza mutare il risultato)
  • all’interno della nostra documentazione non duplichiamo scenari e feature
  • combiniamo gli scenari simili utilizzando gli esempi (blocco Examples)
  • utilizziamo il blocco background per non duplicare il context tra più scenari
  • preferire la scrittura di scenari dichiarativi piuttosto che imperative (vanno bene anche vie di mezzo, dipende dal riuso dello scenario e dalla complessità di realizzarlo descrittivo)

Titolo della feature

  • il titolo deve sempre descrivere una azione (l’azione che potrà essere svolta consegnata la feature). Questo aspetto è importante per definire il perimetro del “finito” una volta consegnato.

Narrazione

  • dovrebbe avere la seguente struttura: “Come [ruolo] voglio [caratteristica] in modo che [beneficio]”

Titoli degli scenari

  • la lettura dei titoli deve evidenziare in modo chiaro e semplice lo scopo degli scenari: per capirne le differenze macroscopiche non deve essere necessario entrare anche nei contenuti di dettaglio

Scenari

  • non devono essere molti, 5 o 6 sono un buon numero. Se sono di più, valuta se si possono scrivere più feature a cui applicare eventualmente uno stesso TAG che li raggruppi per azione / risultati / funzione

Steps

  • la descrizione dello step non deve essere generica (non dobbiamo interpretare per capire ma leggere in modo omnicomprensivo quello che va realizzato)
    Given I click “next” (CATTIVO) vs Given I click “next” out on the “account configuration” page (BUONO !)
  • quando uno step termina con “:” deve essere seguito da un datatable es:

    Then each result should have the following information:
    | information | data_type |
    | title               | string       |

Gestione

  • teniamo traccia degli scenari che spiegano un requisito (tracciabilità, copertura e metriche)
  • inseriamo nella descrizione dello scenario un riferimento al requisito che gli corrisponde
    Scenario: some text description – requirement: REQ-27 (il codice del requisito apparirà nel testo della segnalazione di errore quando il test fallirà)

Se rispetteremo queste regole che ci stiamo dando, oltre a riuscire a scrivere una documentazione Gherkin utilizzabile in una pipeline di sviluppo automatica, stiamo migliorando il livello di qualità, manutenibilità e semplicità di comprensione del nostro progetto.

Sono felice che tu mi abbia accompagnato fino a qui. Nel prossimo articolo ti parlerò di Cucumber, l’implementazione BDD per il linguaggio Java e di come utilizzare le feature Gherkin per eseguire i test automatici del tuo progetto.

A presto !

Seguici

Iscriviti al nostro blog per essere sempre aggiornato