Ci sono molte opzioni disponibili per i team quando si tratta di come scrivere e testare il software. Come si fa a determinare quale sintassi usare e quale soluzione di test è giusta per voi? In questo post, esploreremo l’uso di Gherkin e dei test di Gherkin. Parleremo della sintassi, di come scrivere un test e affronteremo i pro e i contro.
Queste opzioni possono essere una buona scelta nelle giuste circostanze, ma ci sono alcune considerazioni da tenere a mente prima di buttarsi, specialmente quando si considera anche il processo di automazione dei test.
Prima di discutere su cosa sia Gherkin e su come scrivere test Gherkin, ci sono alcune cose che dobbiamo coprire prima. È importante capire il ruolo che gioca il Behavior-Driven Development (BDD) e come questa pratica, Cucumber e Gherkin lavorano insieme.
Che cos’è BBD?
Behavior-Driven Development (BDD) è un metodo di sviluppo che incoraggia la comunicazione tra i team. Questo approccio collaborativo riunisce il business e gli aspetti tecnici dei progetti. Questo metodo permette ai team di comunicare meglio sui requisiti, rilevare i problemi in anticipo e mantenere il software nel tempo con facilità.
I team che usano BBD hanno un paio di obiettivi. Il primo è quello di assicurarsi che i requisiti possano essere compresi da tutto il team. Poi i team possono concentrarsi sulla prevenzione di possibili problemi, piuttosto che spegnere gli incendi se vengono trovati in seguito. Spesso questo significa che è necessaria una minore rielaborazione.
Semplicemente possiamo descrivere questo sviluppo in due fasi. Scoperta e test.
Prima, i team capiscono cosa non sanno PRIMA di iniziare a lavorare. Poi, hanno una migliore comprensione di come rimanere in pista ed essere più produttivi.
Quando si tratta di test, il processo di pensare a questi test inizia prima ancora che lo sviluppo inizi. I test sono scritti per guidare l’implementazione e il prodotto finale.
Che cos’è Cucumber?
Cucumber è uno strumento open-source di test del software che supporta il BBD. (Behavior-Driven Development). Funziona con Gherkin perché la sintassi di Gherkin struttura il testo semplice in modo che possa essere letto dallo strumento.
Cucumber legge i test di Gherkin e convalida che il codice funzioni come dovrebbe. Lo fa lavorando attraverso gli scenari e i passi di Gherkin. (Di più su questo sotto). Cucumber creerà poi un report che mostra se ogni passo e scenario ha avuto successo o se fallisce.
Che cos’è Gherkin?
Gherkin è un linguaggio che gli sviluppatori usano per definire i test in Cucumber. Poiché questo linguaggio usa un semplice inglese, è pensato per descrivere i casi d’uso di un sistema software in un modo che può essere letto e compreso da quasi chiunque.
Questa sintassi promuove lo sviluppo guidato dal comportamento perché permette a sviluppatori, manager, analisti di business e altre parti coinvolte di capire i requisiti del progetto e il ciclo di vita.
Il linguaggio rende facile creare una semplice documentazione del codice che viene scritto. Gherkin fornisce anche script per l’automazione dei test e supporta decine di lingue.
whitepaper
Behavior-driven development. Chi ha bisogno di Gherkin?
Come scrivere test Gherkin
Per scrivere test Gherkin, è necessario prima capire alcune delle parole chiave utilizzate, e cosa fanno in pratica. Ecco una lista delle parole chiave più comuni nella sintassi Gherkin.
- Feature
- Rules
- Example
- Già, Quando, Poi, E, Ma
- Background
- Scenario Outline
Ogni parola chiave è fondamentale per il processo di scrittura di un grande test Gherkin. Ora, diamo un’occhiata più da vicino a queste parole chiave e come usarle per scrivere test Gherkin.
Feature
I documenti Gherkin iniziano con questa parola chiave, seguita da un testo che fornisce una descrizione. Più semplicemente, la caratteristica è una descrizione di ciò che il software dovrebbe fare. Questa parola chiave è anche usata per raggruppare scenari insieme.
Questo non è realmente per scopi di test, ma permette di aggiungere documentazione sui requisiti e sulle regole di business. La sezione descrizione termina quando si inizia una nuova riga con una delle altre parole chiave come scenario outline, esempio o regola.
Descrizioni
Se necessario, le descrizioni in forma libera possono anche essere scritte sotto le parole chiave menzionate sopra, finché nessuna delle tue righe inizia con una parola chiave.
Regola
La parola chiave regola è usata per rappresentare una regola di business che deve essere inclusa. Questo fornisce il contesto per una caratteristica. Queste “regole” dovrebbero avere più di uno scenario per mostrare la regola e possono avere una sezione di sfondo. (Dettagliato sotto).
Passi di Gherkin
Prossimo, diamo un’occhiata ad alcuni dei passi nei test di Gherkin. Questi sono Dato, Quando, Poi, E, o Ma.
Dato
I passi dati impostano la scena per lo scenario. Nella maggior parte dei casi, questi passi descrivono qualcosa che ha avuto luogo nel passato. Questo dà al sistema un contesto prima che un utente inizi ad interagire con esso. Per questo motivo non dovreste coprire le interazioni dell’utente in questo passo. Pensa a ciò che includi in questo passo come precondizioni.
Nota: puoi avere più di un passo Dato.
Quando
I passi Quando sono passi di azione. Descrivono un evento. Esempi potrebbero essere un evento innescato da un altro sistema o da un utente che interagisce con esso. Si raccomanda di avere solo un passo quando per ogni scenario.
Quando
I passi quando sono passi di risultato. Questo è il punto in cui si descrive ciò che si vuole che il sistema faccia in modo da poterlo confrontare con come il software si comporta effettivamente nella pratica. Questo dovrebbe essere qualcosa che si può effettivamente vedere come risultato, come un messaggio o un rapporto.
E, ma
Quando avete diversi di uno dei tipi di passi elencati sopra potete usare e o ma. Questo aiuta a mantenere la tua documentazione organizzata e leggibile.
Sfondo
Come detto sopra, lo sfondo ti permette di aggiungere ancora più contesto agli scenari di una funzione. È qui che si può avere più di un dato passo, se necessario.
Nota: Ci può essere solo un passo di sfondo per ogni caratteristica. Se hai bisogno di più passi di sfondo, dovrai creare diversi file di caratteristiche.
Scenario Outline
Lo scenario outline contiene una sezione di esempi. Questi passi sono letti come un modello. Lo schema dello scenario viene eseguito una volta per ogni riga della sezione degli esempi, ad eccezione della riga dell’intestazione.
Pro e contro dell’uso di Gherkin
Ora che sai come scrivere un test con Gherkin, potresti chiederti come determinare se questa è l’opzione giusta per il tuo team. La verità è che ci sono sia vantaggi che svantaggi nell’usare Gherkin e Cucumber. Diamo un’occhiata più da vicino ad alcuni di essi.
Gherkin è semplice
Al suo interno, Gherkin è facile da capire sia per gli sviluppatori che per i dirigenti aziendali. In un certo senso, è “non tecnico”, rendendo la collaborazione tra i team più facile.
Si concentra sui requisiti del progetto
La sintassi di Gherkin e questo tipo di test si concentra davvero sui requisiti del progetto e del business. Questo assicura un processo di sviluppo costruito con l’esperienza dell’utente in mente.
Riutilizzo del codice
Il modo in cui questi test sono scritti rende più facile il riutilizzo di parti del codice di altri test. Questo può sommarsi, risparmiando tempo, denaro e risorse.
Non per tutti i progetti
Gherkin + Cucumber non è ideale per tutti i tipi di progetto. I progetti brevi che richiedono molti test possono essere ritardati usando questo metodo. Mentre BBD ha un tempo e un luogo, questo modo di pensare e l’implementazione di questi test può rallentare i progetti.
Richiede molto impegno
Questo potrebbe essere un pro o un contro, a seconda della metodologia di sviluppo del tuo team. Come detto prima, Gherkin e Cucumber vanno di pari passo con lo sviluppo guidato dal comportamento. Questo significa che richiede al vostro team di lavorare costantemente in modo collaborativo, il che potrebbe non essere sempre adatto al vostro progetto.
Spesa potenziale
Anche se questi test possono essere più facili da scrivere, un test scritto male può comportare un sacco di tempo extra e denaro sprecato se i test devono essere riscritti. A meno che gli sviluppatori non capiscano Gherkin e Cucumber molto bene, questo tipo di test può essere un enorme rischio finanziario
Il futuro di Gherkin
Qui a Functionize, crediamo che allontanarsi da Gherkin sia il futuro e porterà migliori benefici. Gherkin è un modo in cui le persone scrivono i piani di test, ma non è lì che il processo finisce. Gli sviluppatori devono ancora scrivere script di test. Questo processo può far perdere molto tempo che gli sviluppatori potrebbero spendere altrove.
Gherkin è un buon primo passo per incorporare persone non tecniche nei test di automazione. Ma i nostri clienti si rivolgono al nostro ALP perché ‘tagliamo fuori l’uomo medio’ di dover scrivere lo script Selenium e rendiamo la creazione dei test facile.
Cherkin e Cucumber possono essere una buona scelta quando avete bisogno che tutti nel team siano informati senza scavare negli aspetti tecnici. Tuttavia, a lungo andare, questa combinazione può rendere l’automazione dei test più complicata del necessario.
La scelta è vostra, ma prima di scegliere una sintassi e una soluzione, considerate attentamente i pro e i contro. La cosa più importante è che voi e il vostro team abbiate gli strumenti giusti per i vostri progetti di sviluppo.
Tuttavia, la nostra opinione è che Gherkin è semplicemente troppo poco flessibile e difficile da imparare. La nostra soluzione è il nostro motore Adaptive Language Processing (ALP™), rilasciato di recente. Questo permette di scrivere i test come una serie di passi in semplice inglese.
Questo blog ha esplorato cos’è il testing con Gherkin, come scrivere test con Gherkin e i pro e i contro dell’utilizzo di questa sintassi. Speriamo che questo vi abbia dato un’idea del miglior linguaggio e delle opzioni di test per il vostro prossimo progetto.