Cos'è il linguaggio Gherkin?

Gherkin è un linguaggio di specifica strutturato utilizzato per descrivere il comportamento desiderato di un sistema software in modo che sia comprensibile sia agli stakeholder non tecnici che agli sviluppatori. È il ponte tra i requisiti di business e i test automatizzati, e rappresenta uno degli strumenti fondamentali dello Sviluppo Guidato dal Comportamento (BDD - Behavior-Driven Development).

Il nome "Gherkin" (cetriolino in inglese) deriva dalla sua stretta associazione con Cucumber, il framework di testing più popolare per BDD. Gherkin utilizza una sintassi basata su parole chiave in linguaggio naturale che permette a chiunque di leggere e comprendere le specifiche del software, indipendentemente dal proprio background tecnico.

Secondo il rapporto State of Testing di PractiTest (2023), il 29% dei team di sviluppo nel mondo utilizza approcci BDD con Gherkin o framework simili. Inoltre, uno studio di SmartBear (creatori di Cucumber) indica che i team che adottano BDD riscontrano una riduzione dei difetti del 40% e un miglioramento della collaborazione tra business e sviluppo.

Come sottolinea Dan North, il creatore del BDD, nel suo articolo fondamentale "Introducing BDD" (2006): "Il BDD è nato dalla frustrazione di non capire cosa testare e come descriverlo. Gherkin fornisce un linguaggio comune che elimina l'ambiguità tra ciò che il business vuole e ciò che il software fa."

Cos'è il BDD?

Il Behavior-Driven Development (Sviluppo Guidato dal Comportamento) è una metodologia di sviluppo software che estende il Test-Driven Development (TDD) ponendo l'accento sulla collaborazione tra sviluppatori, tester e stakeholder di business. L'idea centrale è che il software debba essere descritto in termini di comportamento atteso, non di implementazione tecnica.

I tre amigos

In BDD, una pratica fondamentale è la sessione dei "Three Amigos" (Tre Amici), dove tre ruoli chiave collaborano per definire le specifiche:

1. Business/Product Owner: Definisce il "cosa" e il "perché"
2. Sviluppatore: Valuta il "come" e identifica complessità tecniche
3. Tester/QA: Identifica edge case, scenari negativi e criteri di accettazione

Queste sessioni producono scenari Gherkin che servono come documentazione vivente del sistema.

Feature (Funzionalità)

Ogni file Gherkin inizia con la parola chiave Feature, che descrive la funzionalità di alto livello:

Feature: Login utente Come utente registrato Voglio potermi autenticare nella piattaforma Per accedere alle mie informazioni personali

Scenario

Uno Scenario rappresenta un caso d'uso concreto della funzionalità:

Scenario: Login con credenziali valide Given l'utente è nella pagina di login When inserisce email "[email protected]" e password "Password123" And clicca il pulsante "Accedi" Then viene reindirizzato alla dashboard And vede il messaggio "Benvenuto, Mario"

Given-When-Then: il cuore di Gherkin

Le tre parole chiave principali strutturano ogni scenario:

Parola chiave	Significato	Scopo
Given	Dato che...	Definisce lo stato iniziale del sistema (precondizioni)
When	Quando...	Descrive l'azione eseguita dall'utente o dal sistema
Then	Allora...	Specifica il risultato atteso (postcondizioni)

And e But

Per aggiungere condizioni multiple:

Scenario: Registrazione con dati incompleti Given l'utente è nella pagina di registrazione And ha compilato il campo nome con "Mario" But non ha compilato il campo email When clicca il pulsante "Registrati" Then vede un messaggio di errore "L'email è obbligatoria" And il form non viene inviato

Scenario Outline (Schema di Scenario)

Per testare la stessa logica con dati diversi, si utilizza Scenario Outline con una tabella Examples:

Scenario Outline: Validazione password Given l'utente è nella pagina di registrazione When inserisce la password "<password>" Then il sistema mostra "<messaggio>" Examples: | password | messaggio | | abc | La password deve avere almeno 8 caratteri | | abcdefgh | La password deve contenere un numero | | Abcdefg1 | Password valida |

Background

Il Background definisce passi comuni a tutti gli scenari di una feature:

Feature: Gestione carrello Background: Given l'utente è autenticato And ha almeno un prodotto nel catalogo Scenario: Aggiunta prodotto al carrello When aggiunge il prodotto "Laptop Pro" al carrello Then il carrello mostra 1 articolo Scenario: Rimozione prodotto dal carrello Given il carrello contiene il prodotto "Laptop Pro" When rimuove il prodotto "Laptop Pro" Then il carrello è vuoto

Tags

I tag permettono di categorizzare e filtrare gli scenari:

@smoke @login Scenario: Login standard Given l'utente è nella pagina di login ... @regression @carrello Scenario: Aggiunta multipla al carrello ...

Cucumber è il framework che trasforma le specifiche Gherkin in test eseguibili:

Il flusso completo

1. Scrivi le specifiche in file .feature usando la sintassi Gherkin
2. Implementa gli step definitions: codice che collega ogni passo Gherkin a un'azione automatizzata
3. Esegui Cucumber: il framework legge il file .feature, trova gli step definitions corrispondenti e li esegue
4. Analizza i risultati: Cucumber genera report con gli scenari che passano e quelli che falliscono

Esempio di step definition (Java)

@Given("l'utente è nella pagina di login") public void utente_nella_pagina_login() { driver.navigate().to("https://app.esempio.it/login"); } @When("inserisce email {string} e password {string}") public void inserisce_credenziali(String email, String password) { driver.findElement(By.id("email")).sendKeys(email); driver.findElement(By.id("password")).sendKeys(password); } @Then("viene reindirizzato alla dashboard") public void verifica_redirect_dashboard() { assertEquals("https://app.esempio.it/dashboard", driver.getCurrentUrl()); }

Esempio di step definition (JavaScript/TypeScript)

Given('l\'utente è nella pagina di login', async function() { await browser.url('/login'); }); When('inserisce email {string} e password {string}', async function(email, password) { await $('#email').setValue(email); await $('#password').setValue(password); }); Then('viene reindirizzato alla dashboard', async function() { await expect(browser).toHaveUrl('/dashboard'); }); 

Scrivi in modo dichiarativo, non imperativo

Imperativo (da evitare):

When clicca sul campo "email" And digita "[email protected]" And clicca sul campo "password" And digita "Password123" And clicca sul pulsante "Accedi"

Dichiarativo (preferibile):

When effettua il login con email "[email protected]" e password "Password123"

Lo stile dichiarativo è più leggibile, meno fragile ai cambiamenti di UI e si concentra sul comportamento piuttosto che sull'implementazione.

Un scenario, un comportamento

Ogni scenario dovrebbe testare un solo comportamento. Scenari troppo lunghi o che verificano molteplici comportamenti sono difficili da mantenere e debuggare.

Usa il linguaggio del dominio

Scrivi gli scenari usando la terminologia del business, non del codice. Se il business parla di "ordini", non usare "record nel database". Il linguaggio ubiquo (Ubiquitous Language) del Domain-Driven Design si applica perfettamente qui.

Scenari indipendenti

Ogni scenario deve poter essere eseguito in isolamento, senza dipendere dall'esecuzione precedente di altri scenari.

Evita i dettagli di implementazione

Non includere dettagli tecnici come selettori CSS, nomi di tabelle del database o URL specifiche nei file .feature. Questi dettagli appartengono agli step definitions.

Una delle caratteristiche più interessanti di Gherkin è il supporto per oltre 70 lingue. Le parole chiave possono essere scritte in italiano:

# language: it Funzionalità: Gestione ordini Come amministratore del negozio Voglio poter gestire gli ordini Per garantire un servizio efficiente Scenario: Creazione nuovo ordine Dato che il cliente "Mario Rossi" è registrato Quando crea un ordine con il prodotto "Espresso Machine" Allora l'ordine viene creato con stato "In attesa" E viene inviata un'email di conferma

Le parole chiave italiane sono:

• Funzionalità (Feature)
• Scenario (Scenario)
• Dato/Data/Dati (Given)
• Quando (When)
• Allora (Then)
• E (And)
• Ma (But)

Uno dei benefici più significativi di Gherkin è che i file .feature servono come documentazione sempre aggiornata del sistema:

• Se un test fallisce, la documentazione corrispondente è automaticamente segnalata come non valida
• I nuovi membri del team possono leggere i file .feature per capire il comportamento del sistema
• Gli stakeholder possono validare i requisiti leggendo scenari scritti in linguaggio naturale
• La documentazione non può diventare obsoleta perché è eseguita come parte della suite di test

Gherkin è un linguaggio di programmazione?

No. Gherkin è un linguaggio di specifica (DSL - Domain Specific Language) progettato per descrivere il comportamento del software in modo leggibile. Non contiene logica di programmazione: quella è implementata negli step definitions scritti in un linguaggio di programmazione reale.

Chi dovrebbe scrivere gli scenari Gherkin?

Idealmente, gli scenari Gherkin sono scritti collaborativamente durante le sessioni dei Three Amigos. Il Product Owner definisce il comportamento desiderato, il tester identifica edge case e lo sviluppatore valida la fattibilità tecnica.

Gherkin funziona solo con Cucumber?

No. Gherkin è un formato standard supportato da molti framework di testing: SpecFlow (.NET), Behave (Python), Behat (PHP), Karate (API testing) e molti altri. Cucumber è il più noto, ma non l'unico.

Quanti scenari dovrebbe avere una feature?

Non c'è un numero fisso, ma come regola generale una feature dovrebbe avere tra 3 e 10 scenari. Se ha troppi scenari, probabilmente la feature è troppo ampia e dovrebbe essere suddivisa.

Gherkin è adatto per test unitari?

Generalmente no. Gherkin è progettato per test di accettazione e test di integrazione ad alto livello. Per i test unitari, i framework tradizionali (JUnit, pytest, Jest) sono più efficienti e appropriati.