Implementazione degli Scenario Outline di Cucumber nei Framework BDD
Lo sviluppo guidato dal comportamento (BDD) è una pratica di sviluppo software agile che migliora la collaborazione tra le parti interessate e gli sviluppatori utilizzando un linguaggio semplice e specifico del dominio per descrivere il comportamento del sistema.
Uno degli strumenti più potenti nel BDD è Cucumber, che viene usato per scrivere specifiche chiare. Può anche essere utilizzato nei test, con la maggior parte dei linguaggi di programmazione più comuni come Java, Python o C#, e può essere integrato con framework per le interfacce utente, come Selenium, oppure usato per il testing di API.
Gli scenario outline fanno parte della sintassi Gherkin di Cucumber, utilizzata per scrivere specifiche eseguibili. A differenza degli scenari regolari che definiscono un singolo esempio concreto, gli scenario outline permettono di specificare più esempi in un formato tabellare.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Differenze tra Scenario e Scenario Outline
Gli scenari in Cucumber rappresentano un caso di test scritto nella forma di base dato-quando-allora. Il linguaggio Gherkin permette che questi scenari di test siano scritti in inglese semplice (e in altre lingue) così da essere facilmente comprensibili e anche scritti da persone non tecniche. Le definizioni dei passaggi, che rappresentano l'implementazione dei passaggi stessi, sono create in file separati.
Per alcune funzionalità, ha senso ripetere lo stesso scenario utilizzando dati di test diversi – probabilmente lo conosci come test guidato dai dati. In Cucumber, questo si realizza usando lo Scenario Outline con una tabella di esempi che contiene insiemi di dati da utilizzare. Ogni esempio è considerato come un test separato.
Sintassi di Scenario Outline in Cucumber
Un tipico progetto Cucumber contiene file feature, dove vengono definiti i test cucumber, e i file di definizione dei passaggi, con le implementazioni dei passaggi.
Un file feature dovrebbe rappresentare una specifica di requisito e gli scenari utilizzati per testarla. La sintassi di base per uno scenario Cucumber semplice è la seguente:
Scenario: Accesso non valido
Dato che mi trovo sulla pagina di login
Quando inserisco credenziali non valide
Allora ricevo un messaggio di errore
Lo scenario può anche contenere variabili, che verranno trattate come tali nella definizione dei passaggi.
Scenario: Accesso non valido
Dato che mi trovo sulla pagina di login
Quando inserisco nome utente test e password invalid
Allora ricevo un messaggio di errore: "Invalid login".
I valori “test”, “invalid” e “Invalid login” saranno trattati come variabili. Ora vediamo cosa succede quando vogliamo provare diverse combinazioni delle variabili fornite – potremmo finire per avere più scenari, identici tranne che per i valori delle variabili, oppure usare lo scenario outline, che ci permette di utilizzare una tabella in cui definiamo le diverse combinazioni di dati:
Allora ricevo un messaggio di errore: "<messaggio di errore>".
Esempi:
| nome utente | password | messaggio di errore |
| test | invalid | Invalid login |
| test | | Per favore inserisci la password |
| | invalid | Per favore inserisci il nome utente |
La combinazione di dati viene scritta sotto la parola chiave “Esempi”, all’interno di una tabella. Le intestazioni delle tabelle sono i nomi delle variabili, poi ogni riga rappresenta una combinazione di dati. Ogni esempio all'interno di una feature di Cucumber verrà trattato come un caso di test individuale.
Tabella degli Esempi vs Tabelle dei Dati
Le tabelle degli esempi e le tabelle dei dati possono sembrare simili, ma hanno scopi diversi. La differenza principale è che gli esempi vengono usati per implementare scenari guidati dai dati, mentre le tabelle dei dati vengono utilizzate quando i passaggi dello scenario devono utilizzare più variabili.
Una tabella dei dati può essere usata così:
Scenario: Accesso non valido
Dato che mi trovo sulla pagina di login
Quando inserisco le credenziali
| nome utente | password |
| test | invalid |
Allora ricevo un messaggio di errore: "Invalid login".
oppure così:
Scenario: Login non valido
Dato che navigo sulla pagina di login
Quando inserisco le credenziali
| username | test |
| password | invalid |
Allora ricevo un messaggio di errore: "Login non valido".
Le tabelle dati sono particolarmente utili quando i passaggi richiedono più variabili, e sono più leggibili rispetto a quando ciascun valore è scritto all'interno del passaggio.
Lavorare con Data Table e Scenario Outline
Le data table e gli scenario outline possono anche lavorare insieme. Il nome della variabile sarà fornito all'interno della data table e poi riutilizzato nella tabella degli esempi.
Scenario Outline: Login non valido
Dato che navigo sulla pagina di login
Quando inserisco le credenziali
| username | <username> |
| password | <password> |
Allora ricevo un messaggio di errore: "<error message>".
Esempi:
| username | password | messaggio di errore |
| test | invalid | Login non valido |
| test | | Inserire la password |
| | invalid | Inserire lo username |
Vantaggi dell’Utilizzo degli Scenario Outline
Gli scenario outline possono essere interpretati come un “modello” di un caso di test. In pratica, una volta implementati all'interno di un framework di automazione dei test, eseguono lo stesso scenario con differenti set di dati.
Il vantaggio sta nel fatto che c’è meno codice Gherkin e meno ripetizioni. Questo significa che ogni volta che c’è una modifica necessaria nello scenario comune, può essere cambiato una sola volta e il cambiamento verrà applicato a tutte le combinazioni dei dati di test.
Un altro beneficio degli scenario outline è che possono aumentare la copertura dei test con il minimo sforzo. Per aggiungere un nuovo test, basta aggiungere una nuova riga di esempio.
Best practice per scrivere gli Scenario Outline
- Utilizza dati reali: il team è meno propenso a trascurare casi limite o informazioni nascoste quando utilizza casi d’uso reali per comprendere il comportamento.
- Comunica l’obiettivo usando una terminologia di business, in modo che anche gli stakeholder non tecnici e tecnici possano comprendersi meglio.
- Spiega l’intenzione piuttosto che il come verrà implementata; la spiegazione dei passi deve essere il meno tecnica possibile. Questi dovrebbero concentrarsi maggiormente sulle funzioni del sistema piuttosto che sul loro funzionamento.
- Tieni solo ciò che è necessario: per mantenere lo scenario interessante per tutti i partecipanti, non sovraccaricarlo di passaggi inutili.
Da ricordare
Migliorare la Collaborazione: Il BDD migliora la collaborazione tra stakeholder e sviluppatori.
Linguaggio Semplice: Il BDD utilizza un linguaggio semplice e specifico per il dominio per descrivere il comportamento del sistema.
Pratica Agile: Il BDD è una pratica all'interno dello sviluppo software agile.
Coinvolgimento degli Stakeholder: Il BDD coinvolge gli stakeholder nella definizione del comportamento del sistema.
Descrizione del Comportamento di Sistema: Il BDD si concentra sull'efficace descrizione del comportamento del sistema.
Cucumber è un ottimo strumento di collaborazione tra persone non tecniche, sviluppatori e tester. È uno strumento BDD che fornisce specifiche scritte e può essere utilizzato nei test. Possono essere scritti più scenari per mostrare diversi requisiti.
È consigliato usare lo scenario outline con insiemi distinti di valori forniti tramite la tabella degli esempi quando ci si trova di fronte a situazioni in cui gli scenari hanno gli stessi passi ma richiedono diversi valori di dati come input o output.
Iscriviti alla newsletter di The CTO Club per ulteriori approfondimenti.
