Scrivere migliori user stories con Gherkin e Cucumber

Scrivere test unitari automatizzati per il software che costruiamo può sembrare una grande quantità di lavoro senza una chiara ricompensa. Tuttavia, il beneficio a lungo termine per la salute, la felicità e la velocità del vostro team supera l’investimento iniziale. Tra i molti altri benefici, i test automatici catturano i bug, permettono il deployment continuo e rendono più facile per gli sviluppatori partecipare al codice non familiare.

Cucumber è uno strumento che ci permette di creare test automatici del software in un modo facile da scrivere e da leggere. Sebbene molti team di prodotto lottino per far decollare i test automatizzati (forse non avendo mai sentito parlare di strumenti come Cucumber), quasi tutti si sono inconsapevolmente dilettati con uno dei suoi componenti chiave – Gherkin.

Quando usati con giudizio, scrivere criteri di accettazione in forma di Gherkin è un ottimo modo per i team di definire e concordare cosa significa “fatto” per le caratteristiche che costruiscono. Nonostante la sua semplicità, Gherkin è un linguaggio con molte sfumature. Con questa sfumatura arriva un sacco di confusione su ciò che separa una dichiarazione che è scritta bene da una che è scritta male, soprattutto per le persone nuove a Gherkin.

In isolamento, le stranezze di Gherkin possono sembrare confuse, ma quando viste nel contesto dei test automatici di Cucumber, queste sottigliezze hanno molto più senso. Questo articolo esamina come Gherkin e Cucumber stiano bene insieme, in modo che possiate vedere come usare Gherkin in modo più efficace oggi. Alla fine di questo articolo, imparerete come funziona un’implementazione completa di Gherkin + Cucumber e come la costruzione di una libreria di scenari Gherkin ben scritti apre la strada ai test automatici.

Gherkin è un Domain Specific Language per scrivere criteri di accettazione che ha cinque dichiarazioni principali:

Scenario – un’etichetta per il comportamento che si intende descrivere
Given – lo stato iniziale dello scenario
When – una specifica azione che l’utente compie
Then – un risultato testabile, solitamente causato dall’azione in When
And – questo continua uno qualsiasi degli altri tre operatori

Insieme queste dichiarazioni descrivono tutte le azioni che un utente deve compiere per eseguire un compito e il risultato di queste azioni.

Per esempio, un esempio reale di Gherkin potrebbe essere come questo:

Scenario: User clicks the link
Given I am on the homepage
When I click the provided link
Then I should see the link click confirmation

O per generalizzare, come questo:

Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

Generalmente parlando, il Product Manager scrive i criteri di accettazione Gherkin prima che il team inizi a lavorare su una feature. Avere criteri di accettazione delineati in una struttura facile da leggere, facile da capire, rende molto più facile per gli sviluppatori e i designer capire il flusso utente previsto. Questo è prezioso di per sé, ma è solo una piccola parte del valore di Gherkin ben strutturato. Dopo tutto, ci sono molti modi efficaci di scrivere descrizioni di caratteristiche (come: As a ___ I want to ___ so that ___) che possono rendere la comunicazione più facile.

Questi altri approcci hanno il loro posto e in molti casi sono compatibili con Gherkin. Tuttavia, una volta che ci diplomiamo al di là del QA manuale e nei test automatizzati, il vero valore di Gherkin viene alla ribalta. Con alcune tecniche intelligenti, gli scenari inglesi di Gherkin che scriviamo possono essere automaticamente tradotti in codice automatico testabile. Per vedere cosa intendo, diamo una rapida occhiata al fratello maggiore di Gherkin – Cucumber.

Espressioni Regolari

Tradurre gli scenari Gherkin in codice utilizza una tecnologia chiamata Espressioni Regolari, o come viene comunemente chiamata, Regex.

Il problema che Regex risolve è trovare parole, frasi o caratteri specifici all’interno di un corpo di testo. Per raggiungere questo obiettivo, i creatori di Regex hanno definito un insieme di caratteri e simboli che rappresentano la logica dietro la corrispondenza di parti del testo. Per esempio, $ è usato per segnare la fine di una stringa. Come tale, l’espressione regolare fox$ corrisponderebbe a silver fox (perché le ultime tre lettere sono f-o-x) ma non foxy (perché l’ultima lettera è y).

Cucumber usa Regex per analizzare gli scenari che definiamo per le parole chiave di Gherkin (ScenarioGivenWhenThen, e And) e le frasi che le seguono. Quando Cucumber trova una frase che riconosce in uno dei nostri scenari usando Regex, traduce quella frase in codice usando qualcosa chiamato Step Definitions.

Step Definitions

I file di definizione dei passi sono come un dizionario delle lingue straniere. Danno alla nostra suite di test un modo per tradurre i passi dello scenario inglese in codice che possiamo eseguire. Nella maggior parte dei team, gli sviluppatori che costruiranno la feature scrivono le definizioni dei passi.

I file di definizione dei passi assomigliano a questo:

La prima affermazione sta dicendo “ogni volta che trovi la stringa ‘Vado alla homepage’ allora esegui la funzione visit root_path“.

La seconda affermazione sta dicendo “ogni volta che trovate la stringa ‘dovrei vedere il messaggio di benvenuto’ allora ci aspettiamo che la pagina corrente abbia il testo ‘Hello Cucumber’ da qualche parte su di essa”.

Ogni passo di uno scenario dovrebbe avere una definizione di passo in modo che la suite di test automatici sappia come tradurre il nostro inglese in codice. Nel corso del tempo si scriveranno centinaia di queste definizioni di passi, molte delle quali sono riutilizzabili in tutta la suite di test (come il primo passo definito sopra).

Caveat: Riutilizzare le funzioni è possibile solo se usiamo una singola frase per una singola azione. Se i nostri scenari usano siaI go to the homepage che I visit the homepage in modo intercambiabile, allora dobbiamo mantenere due definizioni di passo separate per la stessa azione. Questo codice duplicato rende la nostra suite di test più difficile da mantenere e viola il principio DRY (don’t repeat yourself) dello sviluppo del software.

Come le nostre applicazioni e le nostre suite di test crescono le nostre definizioni dei passi e il nostro numero di scenari crescono insieme ad esse. Questo può diventare rapidamente disordinato e diventare opprimente. Per aiutare ad organizzare le nostre suite di test, usiamo i feature files.

Feature Files

Per aiutare a gestire la complessità di una grande suite di test, raggruppiamo i nostri scenari Gherkin in feature files. I file delle caratteristiche sono come una lista di controllo virtuale per assicurarsi che il software funzioni. Oltre agli scenari necessari per testare una feature, i Feature file hanno anche una breve descrizione della feature e qualsiasi regola di business o informazione aggiuntiva che aiuta a descrivere cosa fa la feature.

Un feature file potrebbe assomigliare a questo:

Feature: Some terse yet descriptive text of what is desired
Textual description of the business value of this feature
Business rules that govern the scope of the feature
Any additional information that will make the feature easier to understand
Scenario: Some determinable business situation
Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too Scenario: A different situation
...

Un’applicazione può (e dovrebbe) avere molti feature file per descrivere il funzionamento delle feature. Questi test lavorano insieme per darvi una panoramica della salute della vostra applicazione.

Output

Quando si esegue la suite di test sulla linea di comando usando Cucumber si ottiene un output come questo:

$ cucumber -s
Using the default profile...
Feature: Hello CucumberScenario: User sees the welcome message
When I go to the login page
Then I should see the welcome message1 scenario (1 passed)
2 steps (2 passed)
0m0.148s

O per qualcosa di più tangibile:

$ cucumber -s
Using the default profile...
Feature: Google Homepage SearchScenario: User sees the header
Given I’m on the homepage
Then I see the headerScenario: User can search with "Google Search”
Given I’m on the homepage
When I type "random page” into the search field
And I click the Google Search button
Then I go to the random page search resultsScenario: User can search with "I’m Feeling Lucky”
Given I’m on the homepage
When I type "random page” into the search field
And I click the I’m Feeling Lucky button
Then I go to a random pageScenario: User can see the Terms and Conditions
...15 scenarios (15 passed)
87 Steps (87 passed)
0m3.141s

Dare un’occhiata all’output dell’esecuzione della vostra suite di test vi dà un modo immediato di controllare la vostra applicazione. Può mostrare dove le vostre modifiche hanno rotto un pezzo della vecchia funzionalità o dove la nuova funzionalità non funziona come progettato. Questo rende facile individuare e correggere questi problemi in modo da poter spedire con fiducia.

Concludendo

Usare Gherkin per scrivere scenari rende semplice mostrare i flussi che il prodotto deve avere. I file delle caratteristiche aiutano ad organizzare questi flussi in pezzi logici. Cucumber analizza questi pezzi e ci dà una lettura dal vivo di quali parti del nostro software funzionano e quali no.

Una suite di test completa dove ogni caratteristica ha un file di caratteristiche e un insieme di scenari è uno strumento potente. Rende facile catturare i bug nelle nuove funzionalità, evitare di introdurre bug nelle vecchie funzionalità e comunicare i progressi con gli stakeholder. Per farla breve, automatizza alcuni dei maggiori ritardi tra la costruzione di una feature e il suo arrivo nelle mani degli utenti.

Utilizzare Gherkin e Cucumber non è l’unico modo per costruire test automatici dei criteri di accettazione, ma è una struttura che è facile da scalare. Puoi iniziare a scrivere Gherkin immediatamente e, man mano che il tuo team matura e cresce, iniziare ad aggiungere i file di passo e i test automatici con Cucumber. Quando sono usati efficacemente, Cucumber e Gherkin ci danno un percorso chiaro (e iterativo!) verso il test unitario completo e automatizzato.