Sviluppo guidato dal comportamento - Guida rapida

Behaviour Driven Development (BDD) è un processo di sviluppo software originariamente emerso da Test Driven Development (TDD).

Secondo Dan North, responsabile dell'evoluzione di BDD, "BDD sta utilizzando esempi a più livelli per creare una comprensione condivisa e un'incertezza superficiale per fornire software che contano".

BDD utilizza esempi per illustrare il comportamento del sistema che sono scritti in un linguaggio leggibile e comprensibile per tutti coloro che sono coinvolti nello sviluppo. Questi esempi includono:

• Convertito in specifiche eseguibili.

• Utilizzato come test di accettazione.

BDD - Caratteristiche principali

Lo sviluppo guidato dal comportamento si concentra su:

• Fornire un processo condiviso e strumenti condivisi che promuovono la comunicazione a sviluppatori di software, analisti aziendali e stakeholder per collaborare allo sviluppo del software, con l'obiettivo di fornire prodotti con valore aziendale.

• Cosa dovrebbe fare un sistema e non su come dovrebbe essere implementato.

• Fornire una migliore leggibilità e visibilità.

• Verificare non solo il funzionamento del software ma anche che soddisfi le aspettative del cliente.

Origine di BDD

Il costo per riparare un difetto aumenta molte volte se il difetto non viene rilevato al momento giusto e riparato come e quando viene rilevato. Considera il seguente esempio.

Ciò dimostra che, a meno che i requisiti non siano ottenuti correttamente, sarebbe costoso riparare i difetti risultanti dall'incomprensione dei requisiti in una fase successiva. Inoltre, il prodotto finale potrebbe non soddisfare le aspettative del cliente.

La necessità del momento è un approccio allo sviluppo che -

• Si basa sui requisiti.

• Si concentra sui requisiti durante lo sviluppo.

• Assicura che i requisiti siano soddisfatti.

Un approccio di sviluppo che può prendersi cura dei requisiti sopra menzionati è BDD. Quindi, lo sviluppo guidato dal comportamento -

• Deriva esempi di diversi comportamenti attesi del sistema.

• Consente di scrivere gli esempi in una lingua utilizzando i termini del dominio aziendale per garantire una facile comprensione da parte di tutti coloro che sono coinvolti nello sviluppo, compresi i clienti.

• Ottiene gli esempi ratificati di volta in volta con il cliente per mezzo di conversazioni.

• Si concentra sui requisiti del cliente (esempi) durante lo sviluppo.

• Utilizza esempi come test di accettazione.

Pratiche BDD

Le due pratiche principali di BDD sono:

• Specifica per esempio (SbE)

• Test Driven Development (TDD)

Specifica per esempio

Specification by Example (SbE) utilizza esempi nelle conversazioni per illustrare le regole aziendali e il comportamento del software da creare.

La specifica per esempio consente ai proprietari del prodotto, agli analisti aziendali, ai tester e agli sviluppatori di eliminare i malintesi comuni sui requisiti aziendali.

Sviluppo basato su test

Test Driven Development, nel contesto di BDD, trasforma gli esempi in specifiche leggibili ed eseguibili.

Gli sviluppatori utilizzano queste specifiche come guida per implementare incrementi di nuove funzionalità. Ciò si traduce in una base di codice snella e una suite di test di regressione automatizzati che mantengono bassi i costi di manutenzione per tutta la durata del software.

Agile BDD

Nello sviluppo di software Agile, il metodo BDD viene utilizzato per giungere a un'intesa comune sulle specifiche in sospeso.

I seguenti passaggi vengono eseguiti in Agile BDD:

• Gli sviluppatori e il proprietario del prodotto scrivono in collaborazione le specifiche in sospeso in un semplice editor di testo.

• Il proprietario del prodotto specifica i comportamenti che si aspettano dal sistema.

• Gli sviluppatori

  • Compila le specifiche con questi dettagli sul comportamento.

  • Poni domande in base alla loro comprensione del sistema.

• Vengono considerati i comportamenti del sistema corrente per vedere se la nuova funzionalità interromperà una delle funzionalità esistenti.

Manifesto Agile e BDD

Il Manifesto Agile afferma quanto segue:

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro, siamo arrivati ​​a valorizzare -

• Individuals and interactions - oltre Processi e strumenti

• Working software - oltre Documentazione completa

• Customer collaboration - Negoziazione su contratto

• Responding to change - oltre a seguire un piano

Cioè, mentre c'è valore negli elementi a destra, diamo più valore agli elementi a sinistra.

BDD si allinea al manifesto Agile come segue:

Manifesto Agile	Allineamento BDD
Individui e interazioni su processi e strumenti.	BDD significa avere conversazioni.
Software funzionante su documentazione completa.	BDD si concentra sulla semplificazione della creazione di software di valore aziendale.
Collaborazione con il cliente nella negoziazione del contratto.	BDD si concentra su scenari basati su idee con comunicazione continua con il cliente man mano che lo sviluppo procede. Non si basa su alcuna promessa.
Rispondere al cambiamento piuttosto che seguire un piano.	BDD si concentra sulla comunicazione e collaborazione continue che facilitano l'assorbimento dei cambiamenti.

Quando guardi qualsiasi riferimento sullo sviluppo guidato dal comportamento, troverai l'uso di frasi come "BDD è derivato da TDD", "BDD e TDD". Per sapere come è nato BDD, perché si dice che derivi da TDD e cosa sono BDD e TDD, devi avere una comprensione di TDD.

Perché testare?

Per iniziare, entriamo nei fondamenti del test. Lo scopo del test è garantire che il sistema creato funzioni come previsto. Considera il seguente esempio.

Quindi, per esperienza abbiamo imparato che scoprire un difetto man mano che viene introdotto e risolverlo immediatamente sarebbe conveniente. Pertanto, è necessario scrivere casi di test in ogni fase di sviluppo e test. Questo è ciò che ci hanno insegnato le nostre pratiche di test tradizionali, che spesso viene definito Test-early.

Questo approccio di test è definito come l'approccio Test-Last poiché il test viene eseguito dopo il completamento di una fase.

Sfide con l'approccio Test-Last

L'approccio Test-Last è stato seguito per parecchio tempo nei progetti di sviluppo software. Tuttavia, in realtà, con questo approccio, poiché il test deve attendere fino al completamento di una determinata fase, spesso viene trascurato a causa di:

• I ritardi nel completamento della tappa.

• Tempi stretti.

• Concentrati sulla consegna in tempo, saltando i test.

Inoltre, nell'approccio Test-Last, il test unitario, che dovrebbe essere fatto dagli sviluppatori, viene spesso ignorato. Le varie ragioni trovate si basano sulla mentalità degli sviluppatori -

• Sono sviluppatori e non tester.

• Il test è responsabilità dei tester.

• Sono efficienti nella codifica e il loro codice non avrebbe difetti.

Ciò si traduce in -

• Compromettere la qualità del prodotto consegnato.

• Avere la responsabilità per la qualità solo sui tester.

• Elevati costi per la riparazione dei difetti, post consegna.

• Incapacità di ottenere la soddisfazione del cliente, il che significherebbe anche la perdita di affari ripetuti, con conseguente credibilità.

Questi fattori hanno richiesto un cambiamento di paradigma, per concentrarsi sui test. Il risultato è stato l'approccio Test-First.

Approccio test-first

L'approccio Test-First sostituisce il modo di sviluppo inside-out (scrivere codice e poi test) con quello outside-in (scrivere test e poi codice).

Questo approccio è incorporato nelle seguenti metodologie di sviluppo software (che sono anche Agile):

• eXtreme Programming (XP).

• Test Dlacerato Dsviluppo (TDD).

In queste metodologie, lo sviluppatore progetta e scrive i test unitari per un modulo di codice prima di scrivere una singola riga del modulo di codice. Lo sviluppatore crea quindi il modulo di codice con l'obiettivo di superare lo unit test. Pertanto, queste metodologie utilizzano i test unitari per guidare lo sviluppo.

Il punto fondamentale è notare che l'obiettivo è lo sviluppo basato sul test.

Ciclo Red-Green-Refactor

Test Driven Development viene utilizzato per sviluppare il codice guidato dai test unitari.

Step 1 - Considera un modulo di codice che deve essere scritto.

Step 2 - Scrivi un test

Step 3 - Esegui il test.

Il test fallisce, poiché il codice non è ancora scritto. Quindi, il passaggio 2 viene solitamente indicato come scrivere un test per fallire.

Step 4 - Scrivere il codice minimo possibile per superare il test.

Step 5- Esegui tutti i test per assicurarti che vengano comunque superati. I test unitari sono automatizzati per facilitare questo passaggio.

Step 6 - Refactoring.

Step 7 - Ripetere i passaggi da 1 a 6 per il modulo di codice successivo.

Ogni ciclo dovrebbe essere molto breve e un'ora tipica dovrebbe contenere molti cicli.

Questo è anche popolarmente noto come Red-Green-Refactor ciclo, dove -

• Red - Scrivere un test che fallisce.

• Green - Scrittura del codice per superare il test.

• Refactor - Rimuovere la duplicazione e migliorare il codice secondo standard accettabili.

Fasi del processo TDD

Le fasi di un processo TDD sono illustrate di seguito.

Vantaggi di TDD

I vantaggi o i vantaggi di Test Driven Development sono:

• Lo sviluppatore deve prima capire quale dovrebbe essere il risultato desiderato e come testarlo prima di creare il codice.

• Il codice per un componente è terminato solo quando il test viene superato e il codice viene riformattato. Ciò garantisce il test e il refactoring prima che lo sviluppatore passi al test successivo.

• Poiché la suite di unit test viene eseguita dopo ogni refactoring, il feedback che ogni componente sta ancora funzionando è costante.

• Gli unit test fungono da documentazione vivente che è sempre all'altezza dei dati.

• Se viene rilevato un difetto, lo sviluppatore crea un test per rivelare quel difetto e quindi modifica il codice in modo che il test venga superato e il difetto venga risolto. Ciò riduce il tempo di debug. Vengono eseguiti anche tutti gli altri test e quando passano, si assicura che la funzionalità esistente non venga interrotta

• Lo sviluppatore può prendere decisioni di progettazione e refactoring in qualsiasi momento e l'esecuzione dei test garantisce che il sistema funzioni ancora. Ciò rende il software gestibile.

• Lo sviluppatore ha la certezza di apportare qualsiasi modifica poiché se la modifica influisce su una funzionalità esistente, la stessa viene rivelata eseguendo i test ei difetti possono essere risolti immediatamente.

• Ad ogni ciclo di prova successivo vengono verificate anche tutte le correzioni di difetti precedenti e la ripetizione dello stesso difetto viene ridotta.

• Poiché la maggior parte dei test viene eseguita durante lo sviluppo stesso, il test prima della consegna viene ridotto.

Svantaggi di TDD

Il punto di partenza sono le User Story, che descrivono il comportamento del sistema. Pertanto, gli sviluppatori spesso affrontano le seguenti domande:

• Quando eseguire il test?

• Cosa testare?

• Come sapere se una specifica è soddisfatta?

• Il codice offre valore aziendale?

Idee sbagliate su TDD

I seguenti malintesi esistono nel settore e necessitano di chiarimenti.

Idea sbagliata	Una precisazione
TDD è interamente dedicato al testing e all'automazione dei test.	TDD è una metodologia di sviluppo che utilizza l'approccio Test-First.
TDD non prevede alcun design.	TDD include analisi critica e progettazione basata sui requisiti. Il design emerge durante lo sviluppo.
TDD è solo a livello di unità.	TDD può essere utilizzato a livello di integrazione e di sistema.
TDD non può essere utilizzato dai tradizionali progetti di test.	TDD è diventato popolare con Extreme Programming e viene utilizzato in altre metodologie Agile. Tuttavia, può essere utilizzato anche in progetti di test tradizionali.
TDD è uno strumento.	TDD è una metodologia di sviluppo e, dopo il superamento di ogni nuovo Unit Test, viene aggiunto all'Automation Test Suite poiché tutti i test devono essere eseguiti ogni volta che viene aggiunto un nuovo codice o viene modificato il codice esistente e anche dopo ogni refactoring. Pertanto, gli strumenti di automazione del test che supportano TDD facilitano questo processo.
TDD significa consegnare i test di accettazione agli sviluppatori.	TDD non significa consegnare i test di accettazione agli sviluppatori.

Accettazione TDD

L'Acceptance Test Driven Development (ATDD) definisce i criteri di accettazione e i test di accettazione durante la creazione di User Story, all'inizio dello sviluppo. ATDD si concentra sulla comunicazione e sulla comprensione comune tra i clienti, gli sviluppatori e i tester.

Le pratiche chiave in ATDD sono le seguenti:

• Discuti gli scenari del mondo reale per costruire una comprensione condivisa del dominio.

• Usa questi scenari per arrivare ai criteri di accettazione.

• Automatizza i test di accettazione.

• Concentra lo sviluppo su quei test.

• Usa i test come specifiche in tempo reale per facilitare il cambiamento.

I vantaggi dell'utilizzo di ATDD sono i seguenti:

• I requisiti sono inequivocabili e senza lacune funzionali.

• Altri capiscono i casi speciali previsti dagli sviluppatori.

• I test di accettazione guidano lo sviluppo.

TDD Vs BDD

Secondo Dan North, i programmatori normalmente affrontano i seguenti problemi durante l'esecuzione di Test Driven Development:

• Dove iniziare

• Cosa testare e cosa non testare

• Quanto testare in una volta

• Come chiamare i loro test

• Come capire perché un test fallisce

La soluzione a tutti questi problemi è lo sviluppo guidato dal comportamento. Si è evoluto dalle pratiche agili consolidate ed è progettato per renderle più accessibili ed efficaci per i team, nuovi alla distribuzione agile del software. Nel tempo, BDD è cresciuta fino a comprendere il quadro più ampio dell'analisi agile e dei test di accettazione automatizzati.

Il principale difference between TDD and BDD è quello -

• TDD descrive come funziona il software.

• D'altra parte, BDD -

  • Descrive come l'utente finale utilizza il software.

  • Favorisce la collaborazione e la comunicazione.

  • Sottolinea gli esempi di comportamento del sistema.

  • Mira alle specifiche eseguibili derivate dagli esempi

In TDD, il termine "Test di accettazione" è fuorviante. I test di accettazione rappresentano effettivamente il comportamento previsto del sistema. Nelle pratiche Agile, viene enfatizzata la collaborazione dell'intero team e le interazioni con il cliente e gli altri stakeholder. Ciò ha determinato la necessità di utilizzare termini facilmente comprensibili da tutte le persone coinvolte nel progetto.

TDD ti fa pensare al necessario Behavior e quindi il termine "comportamento" è più utile del termine ‘Test’. BDD è Test Driven Development con un vocabolario che si concentra sul comportamento e non sui test.

Nelle parole di Dan North, "Ho trovato il passaggio dal pensare nei test al pensare nel comportamento così profondo che ho iniziato a fare riferimento a TDD come BDD, o Behavior Driven Development". TDD si concentra su come funzionerà qualcosa, BDD si concentra sul motivo per cui lo costruiamo.

BDD risponde alle seguenti domande spesso affrontate dagli sviluppatori:

Domanda	Risposta
Dove iniziare?	fuori dentro
Cosa testare?	Storie degli utenti
Cosa non testare?	qualunque altra cosa

Queste risposte risultano nella struttura della storia come segue:

Story Framework

Come un [Role]

Voglio [Feature]

così che [Benefit]

Ciò significa: "Quando a Feature viene eseguito, il risultante Benefit sta alla persona che suona il file Role.'

BDD risponde inoltre alle seguenti domande:

Domanda	Risposta
Quanto testare in una volta?	molto poco concentrato
Come chiamare i loro test?	modello di frase
Come capire perché un test fallisce	documentazione

Queste risposte danno come risultato il framework di esempio:

Example Framework

Given un contesto iniziale,

When si verifica un evento,

Then garantire alcuni risultati.

Ciò significa: "A partire dal contesto iniziale, quando si verifica un evento particolare, sappiamo quali sono i risultati should be. "

Pertanto, l'esempio mostra il comportamento previsto del sistema. Gli esempi vengono utilizzati per illustrare diversi scenari del sistema.

Storia e scenari

Consideriamo la seguente illustrazione di Dan North su un sistema ATM.

Storia

As a cliente,

I want prelevare contanti da un bancomat,

so that Non devo fare la fila in banca.

Scenari

Ci sono due possibili scenari per questa storia.

Scenario 1 - L'account è in credito

Given l'account è in credito

And la carta è valida

And il distributore contiene contanti

When il cliente richiede contanti

Then assicurarsi che l'account venga addebitato

And assicurarsi che il contante venga erogato

And assicurarsi che la carta venga restituita

Scenario 2 - Il conto è scoperto oltre il limite di scoperto

Given il conto è scoperto

And la carta è valida

When il cliente richiede contanti

Then assicurarsi che venga visualizzato un messaggio di rifiuto

And assicurarsi che non vengano erogati contanti

And assicurarsi che la carta venga restituita

L'evento è lo stesso in entrambi gli scenari, ma il contesto è diverso. Quindi, i risultati sono diversi.

Ciclo di sviluppo

Il ciclo di sviluppo per BDD è un outside-in approccio.

Step 1- Scrivi un esempio di valore aziendale di alto livello (esterno) (utilizzando Cucumber o RSpec / Capybara) che diventi rosso. (RSpec produce un framework BDD nel linguaggio Ruby)

Step 2 - Scrivi un esempio RSpec di livello inferiore (interno) per il primo passaggio dell'implementazione che diventa rosso.

Step 3 - Implementa il codice minimo per superare l'esempio di livello inferiore, vederlo diventare verde.

Step 4 - Scrivi il successivo esempio RSpec di livello inferiore spingendo verso il passaggio 1 che diventa rosso.

Step 5 - Ripeti i passaggi Passaggio 3 e Passaggio 4 finché l'esempio di alto livello nel Passaggio 1 diventa verde.

Note - Occorre tenere presenti i seguenti punti:

• Red/green lo stato è uno stato di autorizzazione.

• Quando i tuoi test di basso livello sono verdi, hai il permesso di scrivere nuovi esempi o rifattorizzare l'implementazione esistente. Non devi, nel contesto del refactoring, aggiungere nuove funzionalità / flessibilità.

• Quando i tuoi test di basso livello sono rossi, hai il permesso di scrivere o modificare il codice di implementazione solo per rendere verdi i test esistenti. Devi resistere all'impulso di scrivere il codice per superare il tuo prossimo test, che non esiste, o implementare funzionalità che potresti pensare siano buone (il cliente non l'avrebbe chiesto).

Secondo Gojko Adzic, l'autore di "Specification by Example", Specification by Example è un insieme di schemi di processo che facilitano il cambiamento nei prodotti software per garantire che il prodotto giusto sia consegnato in modo efficiente ".

La specifica per esempio è un approccio collaborativo per definire i requisiti e i test funzionali orientati al business per i prodotti software basati sull'acquisizione e l'illustrazione dei requisiti utilizzando esempi realistici invece di dichiarazioni astratte.

Specifica per esempio - Panoramica

L'obiettivo della specifica per esempio è concentrarsi sullo sviluppo e la fornitura di requisiti aziendali prioritari e verificabili. Sebbene il concetto di specifica per esempio sia di per sé relativamente nuovo, è semplicemente una riformulazione di pratiche esistenti.

Supporta un vocabolario molto specifico e conciso noto come linguaggio onnipresente che:

• Abilita i requisiti eseguibili.

• Viene utilizzato da tutti i membri del team.

• È creato da un team interfunzionale.

• Cattura la comprensione di tutti.

La specifica per esempio può essere utilizzata come input diretto nella creazione di test automatizzati che riflettono il dominio aziendale. Pertanto, il focus della specifica per esempio è sulla costruzione del prodotto giusto e sulla costruzione del prodotto giusto.

Scopo della specifica per esempio

Lo scopo principale della specifica per esempio è costruire il prodotto giusto. Si concentra sulla comprensione condivisa, stabilendo così un'unica fonte di verità. Consente l'automazione dei criteri di accettazione in modo che l'attenzione si concentri sulla prevenzione dei difetti piuttosto che sul rilevamento dei difetti. Promuove anche il test precoce per trovare i difetti in anticipo.

Uso di SbE

La specifica per esempio viene utilizzata per illustrare il comportamento del sistema previsto che descrive il valore aziendale. L'illustrazione è per mezzo di esempi concreti e di vita reale. Questi esempi vengono utilizzati per creare requisiti eseguibili che sono:

• Testabile senza traduzione.

• Catturato nella documentazione live.

Di seguito sono riportati i motivi per cui utilizziamo esempi per descrivere specifiche particolari:

• Sono più facili da capire.

• Sono più difficili da interpretare male.

Vantaggi di SbE

I vantaggi dell'utilizzo della specifica per esempio sono:

• Maggiore qualità

• Riduzione degli sprechi

• Rischio ridotto di difetti di produzione

• Sforzo mirato

• Le modifiche possono essere apportate in modo più sicuro

• Migliore coinvolgimento aziendale

Applicazioni di SbE

Specifica per esempio trova applicazioni in -

• O azienda complessa o organizzazione complessa.

• Non funziona bene per problemi puramente tecnici.

• Non funziona bene per i prodotti software focalizzati sull'interfaccia utente.

• Può essere applicato anche a sistemi legacy.

SbE e test di accettazione

I vantaggi della specifica per esempio in termini di test di accettazione sono:

• Una singola illustrazione viene utilizzata sia per i requisiti dettagliati che per i test

• Lo stato di avanzamento del progetto è in termini di Test di accettazione -

  • Ogni test serve a testare un comportamento.

  • Un test sta passando per un comportamento o non lo è.

  • Un test di superamento rappresenta che il comportamento particolare è stato completato.

  • Se un progetto che richiede 100 comportamenti per essere completato ha 60 comportamenti completati, allora è completato al 60%.

• I tester passano dalla correzione dei difetti alla prevenzione dei difetti e contribuiscono alla progettazione della soluzione.

• L'automazione consente la comprensione immediata dell'impatto di una modifica dei requisiti sulla soluzione.

Specifica per esempio: cosa significa per ruoli diversi

L'obiettivo della specifica per esempio è promuovere la collaborazione di tutti i membri del team, incluso il cliente durante tutto il progetto, per fornire valore aziendale. Tutti per una migliore comprensibilità usano lo stesso vocabolario.

Ruolo	Uso di SbE
Analista di affari	I requisiti sono inequivocabili e senza lacune funzionali. Sviluppatori, in realtà leggono le specifiche.
Sviluppatore	Gli sviluppatori capiscono meglio cosa si sta sviluppando. Il progresso dello sviluppo viene monitorato meglio contando le specifiche sviluppate correttamente.
Tester	I tester capiscono meglio ciò che viene testato. I tester sono coinvolti sin dall'inizio e hanno un ruolo nella progettazione. I tester lavorano per la prevenzione dei difetti piuttosto che per il rilevamento dei difetti.
Tutti	Il tempo si risparmia identificando gli errori dall'inizio. Fin dall'inizio si produce un prodotto di qualità.

SbE - Una serie di modelli di processo

Come abbiamo visto all'inizio di questo capitolo, la specifica per esempio è definita come un insieme di schemi di processo che facilitano il cambiamento nei prodotti software per garantire che il prodotto giusto sia consegnato in modo efficiente.

I modelli di processo sono:

• Specifica collaborativa

• Illustrare le specifiche utilizzando esempi

• Affinamento delle specifiche

• Automatizzare gli esempi

• Convalida frequentemente

• Documentazione vivente

Specifica collaborativa

Gli obiettivi della specifica collaborativa sono:

• Ottieni i vari ruoli in una squadra per avere una comprensione comune e un vocabolario condiviso.

• Coinvolgi tutti nel progetto in modo che possano contribuire con le loro diverse prospettive su una caratteristica.

• Garantire una comunicazione condivisa e la proprietà delle funzionalità.

Questi obiettivi vengono raggiunti in un seminario sulle specifiche noto anche come riunione dei Tre Amigos. I tre Amigo sono BA, QA e lo sviluppatore. Sebbene ci siano altri ruoli nel progetto, questi tre sarebbero responsabili e responsabili dalla definizione alla consegna delle caratteristiche.

During the meeting −

• Il Business Analyst (BA) presenta i requisiti e i test per una nuova funzionalità.

• I tre Amigo (BA, Developer e QA) discutono la nuova funzionalità e rivedono le specifiche.

• Il QA e lo sviluppatore identificano anche i requisiti mancanti.

• I tre Amigo

  • Utilizza un modello condiviso utilizzando un linguaggio onnipresente.

  • Usa il vocabolario del dominio (un glossario viene mantenuto se necessario).

  • Cerca differenze e conflitti.

• Non saltare ai dettagli di implementazione a questo punto.

• Raggiungi un consenso sul fatto che una caratteristica sia stata specificata sufficientemente.

• Un senso condiviso dei requisiti e della proprietà dei test facilita le specifiche di qualità

• I requisiti sono presentati come scenari, che forniscono requisiti espliciti e non ambigui. Uno scenario è un esempio del comportamento del sistema dal punto di vista degli utenti.

Illustrare le specifiche utilizzando esempi

Gli scenari vengono specificati utilizzando la struttura Dato-Quando-Allora per creare una specifica verificabile -

Given <qualche precondizione>

And <condizioni preliminari aggiuntive> Optional

When <si verifica un'azione / trigger>

Then <qualche condizione del post>

And <condizioni post aggiuntive> Optional

Questa specifica è un esempio di un comportamento del sistema. Rappresenta anche un criterio di accettazione del sistema.

Il team discute gli esempi e il feedback viene incorporato finché non si concorda sul fatto che gli esempi coprono il comportamento previsto della funzionalità. Ciò garantisce una buona copertura del test.

Affinamento della specifica

Per perfezionare una specifica,

• Sii preciso nello scrivere gli esempi. Se un esempio si rivela complesso, suddividilo in esempi più semplici.

• Concentrati sulla prospettiva aziendale ed evita i dettagli tecnici.

• Considera condizioni sia positive che negative.

• Attenersi al vocabolario specifico del dominio.

• Discuti gli esempi con il cliente.

  • Scegli le conversazioni per farlo.

  • Considera solo quegli esempi a cui il cliente è interessato. Ciò consente la produzione solo del codice richiesto ed evita di coprire ogni possibile combinazione, che potrebbe non essere richiesta

• Per garantire che lo scenario venga superato, devono essere superati tutti i casi di test per quello scenario. Quindi, migliorare le specifiche per renderle testabili. I casi di test possono includere vari intervalli e valori dei dati (boundary e corner case) nonché diverse regole di business che comportano modifiche nei dati.

• Specificare regole di business aggiuntive come calcoli complessi, manipolazione / trasformazione dei dati, ecc.

• Includere scenari non funzionali (ad esempio prestazioni, carico, usabilità, ecc.) Come Specifica per esempio

Esempi di automazione

Il livello di automazione deve essere mantenuto molto semplice: basta collegare la specifica al sistema in prova. Puoi usare uno strumento per lo stesso.

Esegui l'automazione dei test utilizzando il linguaggio DSL (Domain Specific Language) e mostra una chiara connessione tra input e output. Concentrati sulle specifiche e non sullo script. Assicurati che i test siano precisi, facili da capire e verificabili.

Convalida frequentemente

Includere la convalida di esempio nella pipeline di sviluppo con ogni modifica (aggiunta / modifica). Esistono molte tecniche e strumenti che possono (e dovrebbero) essere adottati per garantire la qualità di un prodotto. Ruotano attorno a tre principi chiave:Test Early, Test Well e Test Often.

Eseguire i test frequentemente in modo da poter identificare i collegamenti deboli. Gli esempi che rappresentano i comportamenti aiutano a tenere traccia dei progressi e si dice che un comportamento sia completo solo dopo il superamento del test corrispondente.

Documentazione vivente

Mantieni le specifiche il più semplici e brevi possibile. Organizza le specifiche ed evolvile man mano che il lavoro procede. Rendi la documentazione accessibile a tutti i membri del team.

Specifica tramite passaggi di processo di esempio

L'illustrazione mostra le fasi del processo in Specifica per esempio.

Anti-modelli

Gli anti-pattern sono determinati modelli nello sviluppo del software che sono considerati una cattiva pratica di programmazione. Al contrario dei modelli di progettazione, che sono approcci comuni a problemi comuni, che sono stati formalizzati e sono generalmente considerati una buona pratica di sviluppo, gli anti-modelli sono l'opposto e non sono desiderabili

Gli anti-pattern danno origine a vari problemi.

Anti-pattern	I problemi
Nessuna collaborazione	Molte ipotesi Costruire cosa sbagliata Testare cosa sbagliata Ignaro quando il codice è finito
Ignaro quando il codice è finito	Difficile mantenere i test Spec. Difficile da capire Perdita di interesse da parte dei rappresentanti delle imprese
Esempi troppo dettagliati o troppo incentrati sull'interfaccia utente	Difficile mantenere i test Specifiche difficili da capire Perdita di interesse da parte dei rappresentanti delle imprese
Sottovalutare lo sforzo richiesto	Le squadre pensano di aver fallito e rimangono deluse presto

Soluzione ai problemi - Qualità

La qualità può essere garantita tenendo d'occhio gli anti-modelli. Per ridurre al minimo i problemi creati dagli anti-pattern, dovresti:

• Riunisciti per specificare utilizzando esempi.

• Pulisci e migliora gli esempi.

• Scrivi un codice che soddisfi gli esempi

• Automatizza gli esempi e distribuisci.

• Ripeti l'approccio per ogni user story.

Risolvere i problemi dovuti agli anti-pattern significa aderire a -

• Collaboration.

• Concentrandosi su cosa.

• Concentrandosi sul business.

• Essere preparato.

Cerchiamo di capire cosa significano ognuna delle precedenti.

Collaborazione

In collaborazione -

• Gli uomini d'affari, gli sviluppatori e i tester danno input dal loro punto di vista.

• Gli esempi automatizzati dimostrano che il team ha costruito la cosa corretta.

• Il processo è più prezioso dei test stessi.

Concentrandosi su cosa

Devi concentrarti sulla domanda: "cosa". Mentre ci si concentra su 'cosa' -

• Non cercare di coprire tutti i casi possibili.

• Non dimenticare di utilizzare diversi tipi di test.

• Mantieni gli esempi il più semplici possibile.

• Gli esempi dovrebbero essere facilmente comprensibili dagli utenti del sistema.

• Gli strumenti non dovrebbero svolgere un ruolo importante nei seminari.

Concentrandosi sul business

Per concentrarsi sul business -

• Mantieni le specifiche secondo l'intento aziendale.

• Includere l'attività nella creazione e revisione delle specifiche.

• Nascondi tutti i dettagli nel livello di automazione.

Essere preparato

Preparati per quanto segue:

• I vantaggi non sono immediatamente evidenti, anche se le pratiche di squadra sono cambiate.

• L'introduzione di SbE è impegnativo.

• Richiede tempo e investimenti.

• I test automatizzati non sono gratuiti.

Utensili

L'uso di strumenti non è obbligatorio per la specifica mediante esempio, sebbene in pratica siano disponibili diversi strumenti. Ci sono casi che hanno successo seguendo la specifica per esempio anche senza utilizzare uno strumento.

I seguenti strumenti supportano la specifica per esempio:

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog

I team di sviluppo spesso hanno un'idea sbagliata che BDD sia un framework di strumenti. In realtà, BDD è un approccio di sviluppo piuttosto che un framework di strumenti. Tuttavia, come nel caso di altri approcci di sviluppo, esistono anche strumenti per BDD.

Diversi strumenti BDD sono in uso per diverse piattaforme e linguaggi di programmazione. Sono -

• Cetriolo (quadro rubino)

• SpecFlow (.NET framework)

• Comportarsi (framework Python)

• JBehave (framework Java)

• JBehave Web (framework Java con integrazione Selenium)

• Lettuce (framework Python)

• Concordion (framework Java)

• Behat (framework PHP)

• Kahlan (framework PHP)

• DaSpec (framework JavaScript)

• Jasmine (framework JavaScript)

• Cucumber-js (framework JavaScript)

• Squish GUI Tester (BDD GUI Testing Tool per JavaScript, Python, Perl, Ruby e Tcl)

• Spock (framework Groovy)

• Yadda (supporto del linguaggio Gherkin per framework come Jasmine (framework JavaScript))

Cetriolo

Cucumber è uno strumento gratuito per le specifiche eseguibili utilizzate a livello globale. Cucumber consente ai team di sviluppo del software di descrivere come dovrebbe comportarsi il software in testo normale. Il testo è scritto in un linguaggio specifico del dominio leggibile per il business e funge da documentazione, test automatizzati e supporto allo sviluppo, il tutto riunito in un unico formato. Puoi usare oltre quaranta lingue parlate diverse (inglese, cinese, ecc.) Con Cucumber.

Cetriolo - Caratteristiche principali

Le caratteristiche principali del cetriolo sono le seguenti:

• Il cetriolo può essere utilizzato per le specifiche eseguibili, l'automazione dei test e la documentazione vivente.

• Cucumber funziona con Ruby, Java, NET, Flex o applicazioni web scritte in qualsiasi lingua.

• Il cetriolo supporta test più succinti nelle tabelle, in modo simile a ciò che fa FIT.

• Cucumber ha rivoluzionato il ciclo di vita dello sviluppo del software fondendo requisiti, test automatizzati e documentazione in uno coerente: specifiche eseguibili in testo semplice che convalidano il software.

SpecFlow

SpecFlow è uno strumento BDD per la piattaforma .NET. SpecFlow è un progetto open source. Il codice sorgente è ospitato su GitHub.

SpecFlow utilizza la sintassi di Gherkin per le funzionalità. Il formato Gherkin è stato introdotto da Cucumber ed è utilizzato anche da altri strumenti. Il linguaggio Gherkin è mantenuto come progetto su GitHub -https://github.com/cucumber/gherkin

Comportarsi

Behave è usato per il framework Python.

• Behave funziona con tre tipi di file memorizzati in una directory chiamata "caratteristiche":

  • file di funzionalità con i tuoi scenari di comportamento in esso.

  • Directory "steps" con implementazioni di passi Python per gli scenari.

  • Facoltativamente, alcuni controlli ambientali (codice da eseguire prima e dopo passaggi, scenari, funzionalità o l'intera partita di tiro).

• Le caratteristiche di Behave sono scritte usando Gherkin (con alcune modifiche) e sono denominate "name.feature".

• I tag associati a una funzionalità e uno scenario sono disponibili nelle funzioni dell'ambiente tramite l'oggetto "funzionalità" o "scenario" passato a loro. Su quegli oggetti c'è un attributo chiamato "tag" che è un elenco dei nomi dei tag allegati, nell'ordine in cui si trovano nel file delle caratteristiche.

• Modifiche allo standard Gherkin -

  • Behave può analizzare i file Gherkin standard ed estende Gherkin per consentire parole chiave con passaggi minuscoli perché a volte possono consentire specifiche di funzionalità più leggibili

Lattuga

La lattuga è uno strumento BDD molto semplice basato sul cetriolo. Può eseguire descrizioni funzionali in testo semplice come test automatizzati per progetti Python. La lattuga mira ai compiti più comuni su BDD.

Concordione

Concordion è uno strumento open source per l'automazione di Specification by Example per Java Framework.

Sebbene le funzionalità principali siano semplici, la potente API del framework di estensione consente di aggiungere funzionalità, come l'utilizzo di fogli di calcolo Excel come specifiche, l'aggiunta di schermate all'output, la visualizzazione delle informazioni di registrazione, ecc.

Concordion ti consente di scrivere le specifiche in un linguaggio normale utilizzando paragrafi, tabelle e punteggiatura corretta e il linguaggio strutturato utilizzando Dato / Quando / Allora non è necessario.

Concordion è stato portato in altre lingue, tra cui:

• C # (Concordion.NET)

• Python (PyConcordion)

• Ruby (Ruby-Concordion)

Cucumber è uno strumento che supporta le specifiche eseguibili, l'automazione dei test e la documentazione Living.

Lo sviluppo guidato dal comportamento si espande sulle specifiche per esempio. Formalizza inoltre le migliori pratiche di sviluppo basato sui test, in particolare, la prospettiva di lavorare dall'esterno all'interno. Il lavoro di sviluppo si basa su specifiche eseguibili.

Il key features delle specifiche eseguibili sono le seguenti:

• Le specifiche eseguibili sono:

  • Derivato da esempi, che rappresentano i comportamenti del sistema.

  • Scritto con la collaborazione di tutte le persone coinvolte nello sviluppo, comprese le imprese e le parti interessate.

  • Basato sul criterio di accettazione.

• I test di accettazione basati sulle specifiche eseguibili sono automatizzati.

• Un linguaggio condiviso e onnipresente viene utilizzato per scrivere le specifiche eseguibili e i test automatizzati in modo tale che:

  • La terminologia specifica del dominio viene utilizzata durante lo sviluppo.

  • Tutti, compresi i clienti e gli stakeholder, parlano del sistema, dei suoi requisiti e della sua implementazione, allo stesso modo.

  • Gli stessi termini sono usati per discutere il sistema presente nei requisiti, documenti di progetto, codice, test, ecc.

  • Chiunque può leggere e comprendere un requisito e come generare più requisiti.

  • Le modifiche possono essere facilmente adattate.

  • La documentazione live viene mantenuta.

Cucumber aiuta con questo processo poiché collega le specifiche eseguibili con il codice effettivo del sistema e i test di accettazione automatizzati.

Il modo in cui lo fa è in realtà progettato per far lavorare insieme clienti e sviluppatori. Quando un test di accettazione ha esito positivo, significa che la specifica del comportamento del sistema che rappresenta è stata implementata correttamente.

Tipico test di accettazione del cetriolo

Considera il seguente esempio.

Feature − Sign up

• La registrazione dovrebbe essere rapida e amichevole.

• Scenario: iscrizione riuscita

  • New gli utenti dovrebbero ricevere un'e-mail di conferma ed essere accolti personalmente.

  • Given Ho scelto di iscrivermi.

  • When Mi iscrivo con dati validi.

  • Then Dovrei ricevere un'e-mail di conferma.

  • And Dovrei vedere un messaggio di saluto personalizzato.

Da questo esempio, possiamo vedere che:

• Le prove di accettazione si riferiscono a Features.

• Le caratteristiche sono spiegate da Scenarios.

• Gli scenari sono costituiti da Steps.

La specifica è scritta in un linguaggio naturale in un file di testo semplice, ma è eseguibile.

Lavorazione del cetriolo

Cucumber è uno strumento da riga di comando che elabora i file di testo contenenti le funzionalità alla ricerca di scenari che possono essere eseguiti sul tuo sistema. Facci capire come funziona il cetriolo.

• Si avvale di una serie di convenzioni su come vengono denominati i file e dove si trovano (le rispettive cartelle) per facilitare l'avvio.

• Cucumber ti consente di conservare le specifiche, i test automatizzati e la documentazione nello stesso posto.

• Ogni scenario è un elenco di passaggi che descrivono le condizioni preliminari, le azioni e le condizioni successive dello scenario; se ogni passaggio viene eseguito senza alcun errore, lo scenario viene contrassegnato come superato.

• Alla fine di una corsa, Cucumber riporterà quanti scenari sono passati.

• Se qualcosa non funziona, fornisce informazioni su cosa non è riuscito in modo che lo sviluppatore possa progredire.

In Cetriolo, Features, Scenariose i passaggi sono scritti in una lingua chiamata Gherkin.

Gherkin è un inglese a testo semplice (o una delle oltre 60 altre lingue) con una struttura. Gherkin è facile da imparare e la sua struttura consente di scrivere esempi in modo conciso.

• Cucumber esegue i file che contengono specifiche eseguibili scritte in Gherkin.

• Cucumber ha bisogno delle definizioni dei passaggi per tradurre i passaggi del cetriolino in testo normale in azioni che interagiranno con il sistema.

• Quando Cucumber esegue un passaggio in uno scenario, cercherà una definizione del passaggio corrispondente da eseguire.

• Una definizione di passaggio è una piccola parte di codice con un modello allegato.

• Il modello viene utilizzato per collegare la definizione del passaggio a tutti i passaggi corrispondenti e il codice è ciò che Cucumber eseguirà quando vede un passaggio Gherkin.

• Ogni passaggio è accompagnato da una definizione di passaggio.

• La maggior parte dei passaggi raccoglierà input e quindi delegherà a un framework specifico per il dominio dell'applicazione per effettuare chiamate sul framework.

Cucumber supporta oltre una dozzina di piattaforme software diverse. Puoi scegliere l'implementazione di Cucumber che funziona per te. Ogni implementazione di Cucumber fornisce la stessa funzionalità complessiva e hanno anche la propria procedura di installazione e funzionalità specifiche della piattaforma.

Mappatura dei passaggi e definizioni dei passaggi

La chiave di Cucumber è la mappatura tra i passaggi e le definizioni dei passaggi.

Implementazioni di cetriolo

Di seguito sono riportate le implementazioni di Cucumber.

	Ruby / JRuby
	JRuby (utilizzando Cucumber-JVM)
	Giava
	Groovy
	.NET (utilizzando SpecFlow)
	JavaScript
	JavaScript (utilizzando Cucumber-JVM e Rhino)
	Clojure
	Gosu
	Lua
	PHP (utilizzando Behat)
	Jython
	C ++
	Tcl

Integrazione del framework

Di seguito sono riportate le implementazioni del Framework.

	Ruby on Rails
	Selenio
	PicoContainer
	Quadro di primavera
	Watir

Il cetriolino è una lingua usata per scrivere Features, Scenarios, and Steps. Lo scopo di Gherkin è quello di aiutarci a scrivere requisiti concreti.

Per capire cosa si intende per requisiti concreti, si consideri il seguente esempio:

Ai clienti dovrebbe essere impedito di inserire dettagli della carta di credito non validi.

Contro

Se un cliente inserisce un numero di carta di credito che non è esattamente di 16 cifre, quando tenta di inviare il modulo, dovrebbe essere visualizzato di nuovo con un messaggio di errore che lo informa del numero corretto di cifre.

Quest'ultimo non ha ambiguità ed evita errori ed è molto più testabile.

Gherkin è progettato per creare requisiti più concreti. In Gherkin, l'esempio sopra ha il seguente aspetto:

Feature

Feedback quando si inseriscono dati di carta di credito non validi Feature Definition

Nei test degli utenti, abbiamo visto molte persone che commettono errori Documentazione

Background True for all Scenarios Below

Given Ho scelto un oggetto da acquistare,

And Sto per inserire il numero della mia carta di credito

Scenario - Numero di carta di credito troppo breveScenario Definition

When Inserisco un numero di carta di lunghezza inferiore a 16 cifre

And tutti gli altri dettagli sono corretti

And Invio il moduloSteps

Then il modulo dovrebbe essere visualizzato nuovamente

And Dovrei vedere un messaggio che mi informa del numero corretto di cifre

Formato e sintassi di Gherkin

I file Gherkin sono file di testo semplice e hanno l'estensione .feature. Ogni riga che non è vuota deve iniziare con una parola chiave Gherkin, seguita dal testo che ti piace. Le parole chiave sono:

• Feature

• Scenario

• Dato, Quando, Allora, E, Ma (Passi)

• Background

• Schema dello scenario

• Examples

• "" "(Doc Strings)

• | (Tabelle dati)

• @ (Tag)

• # (Commenti)

• *

Caratteristica

Il FeatureLa parola chiave viene utilizzata per descrivere una funzionalità del software e per raggruppare gli scenari correlati. Una caratteristica ha tre elementi di base:

• La parola chiave: caratteristica.

• Il nome della funzionalità, fornito sulla stessa riga della parola chiave Feature.

• Una descrizione facoltativa (ma altamente consigliata) che può estendersi su più righe, ovvero tutto il testo compreso tra la riga contenente la parola chiave Feature e una riga che inizia con Scenario, Sfondo o Struttura dello scenario.

Oltre a un nome e una descrizione, le funzionalità contengono un elenco di scenari o schemi di scenari e uno sfondo opzionale.

È convenzionale nominare un file .featurefile prendendo il nome del Feature, convertendolo in minuscolo e sostituendo gli spazi con sottolineature. Per esempio,

feedback_when_entering_invalid_credit_card_details.feature

Per identificare le funzionalità nel sistema, è possibile utilizzare ciò che è noto come "modello di iniezione di funzionalità".

Per <raggiungere un obiettivo> come <tipo di utente> voglio una <a funzionalità>

Descrizioni

Alcune parti dei documenti Gherkin non devono iniziare con una parola chiave.

Nelle righe che seguono una caratteristica, uno scenario, uno schema di scenario o degli esempi, puoi scrivere qualsiasi cosa tu voglia, purché nessuna riga inizi con una parola chiave. Questo è il modo per includere le descrizioni.

Scenario

Per esprimere il comportamento del tuo sistema, allega uno o più scenari a ciascuna caratteristica. È tipico vedere da 5 a 20 scenari per caratteristica per specificare completamente tutti i comportamenti attorno a quella caratteristica.

Gli scenari seguono il seguente schema:

• Descrivi un contesto iniziale

• Descrivi un evento

• Descrivi un risultato atteso

Iniziamo con un contesto, descriviamo un'azione e controlliamo il risultato. Questo viene fatto con passaggi. Gherkin fornisce tre parole chiave per descrivere ciascuno dei contesti, azioni e risultati come passaggi.

• Given - Stabilisci il contesto

• When - Eseguire l'azione

• Then - Controlla il risultato

Queste parole chiave forniscono la leggibilità dello scenario.

Example

Scenario - Prelevare denaro dal conto.

• Given Ho $ 100 nel mio account.

• When Chiedo $ 20.

• Then $ 20 dovrebbero essere erogati.

Se sono presenti più file Given o When gradini uno sotto l'altro, puoi usare And o But. Consentono di specificare gli scenari in dettaglio.

Example

Scenario - Tentativo di ritiro utilizzando la carta rubata.

• Given Ho $ 100 nel mio account.

• But la mia carta non è valida.

• When Chiedo $ 50.

• Then la mia carta non deve essere restituita.

• And Mi dovrebbe essere detto di contattare la banca.

Durante la creazione degli scenari, ricorda che "ogni scenario deve avere un senso ed essere in grado di essere eseguito indipendentemente da qualsiasi altro scenario". Ciò significa:

• Non è possibile fare in modo che la condizione di successo di uno scenario dipenda dal fatto che un altro scenario è stato eseguito prima di esso.

• Ogni scenario crea il proprio contesto particolare, esegue una cosa e verifica il risultato.

Tali scenari forniscono i seguenti vantaggi:

• I test saranno più semplici e più facili da capire.

• Puoi eseguire solo un sottoinsieme dei tuoi scenari e non devi preoccuparti della rottura del tuo set di test.

• A seconda del tuo sistema, potresti essere in grado di eseguire i test in parallelo, riducendo la quantità di tempo necessaria per eseguire tutti i tuoi test.

Schema dello scenario

Se devi scrivere scenari con più input o output, potresti finire per creare diversi scenari che differiscono solo per i loro valori. La soluzione è utilizzare lo schema dello scenario. Per scrivere uno schema di scenario,

• Le variabili nei passaggi della struttura dello scenario sono contrassegnate con <e>.

• I vari valori per le variabili sono forniti come esempi in una tabella.

Example

Supponi di scrivere una caratteristica per aggiungere due numeri su una calcolatrice.

Feature - Aggiungi.

Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input    | output |
| 2+2      | 4      | 
| 98+1     | 99     |
| 255+390  | 645    |

Una sezione della struttura dello scenario è sempre seguita da una o più sezioni di esempi, che sono un contenitore per una tabella. La tabella deve avere una riga di intestazione corrispondente alle variabili nei passaggi della struttura dello scenario. Ciascuna delle righe seguenti creerà un nuovo scenario, inserendo i valori delle variabili

SpecFlow è un progetto open source. Il codice sorgente è ospitato su GitHub. I file di funzionalità utilizzati da SpecFlow per memorizzare un criterio di accettazione per le funzionalità (casi d'uso, storie utente) nell'applicazione vengono definiti utilizzando la sintassi di Gherkin.

Il formato Gherkin è stato introdotto da Cucumber ed è utilizzato anche da altri strumenti. Il linguaggio Gherkin è mantenuto come progetto su GitHub -https://github.com/cucumber/gherkin

Elementi di funzionalità e SpecFlow

Le caratteristiche principali degli elementi Feature sono:

• L'elemento feature fornisce un'intestazione per il file feature. L'elemento funzionalità include il nome e una descrizione di alto livello della funzionalità corrispondente nell'applicazione.

  • SpecFlow genera una classe di unit test per l'elemento feature, con il nome della classe derivato dal nome della feature.

  • SpecFlow genera unit test eseguibili dagli scenari che rappresentano i criteri di accettazione.

• Un file di funzionalità può contenere più scenari utilizzati per descrivere i test di accettazione della funzionalità.

  • Gli scenari hanno un nome e possono essere costituiti da più passaggi dello scenario.

  • SpecFlow genera un metodo di unit test per ogni scenario, con il nome del metodo derivato dal nome dello scenario.

Più passaggi dello scenario

Gli scenari possono avere più passaggi dello scenario. Esistono tre tipi di passaggi che definiscono le condizioni preliminari, le azioni o le fasi di verifica che compongono il test di accettazione.

• I diversi tipi di passaggi iniziano con il file Given, When o Then le parole chiave rispettivamente e i passaggi successivi dello stesso tipo possono essere collegati utilizzando il And e But parole chiave.

• La sintassi Gherkin consente qualsiasi combinazione di questi tre tipi di passaggi, ma uno scenario di solito ha blocchi distinti di Given, When e Then dichiarazioni.

• I passaggi dello scenario vengono definiti utilizzando il testo e possono avere una tabella aggiuntiva denominata DataTable o testo multilinea denominato DocString arguments.

• I passaggi dello scenario sono un modo principale per eseguire qualsiasi codice personalizzato per automatizzare l'applicazione.

• SpecFlow genera una chiamata all'interno del metodo di unit test per ogni passaggio dello scenario. La chiamata viene eseguita dal runtime SpecFlow che eseguirà la definizione del passaggio corrispondente al passaggio dello scenario.

• La corrispondenza viene eseguita in fase di esecuzione, quindi i test generati possono essere compilati ed eseguiti anche se l'associazione non è ancora implementata.

• È possibile includere tabelle e argomenti su più righe nei passaggi dello scenario. Questi vengono utilizzati dalle definizioni dei passaggi e vengono passati come tabelle aggiuntive o come argomenti di stringa.

Tag

I tag sono indicatori che possono essere assegnati a funzionalità e scenari. Assegnare un tag a una funzionalità equivale ad assegnare il tag a tutti gli scenari nel file di funzionalità. Un nome tag con una @ iniziale indica un tag.

• Se supportato dal framework di unit test, SpecFlow genera categorie dai tag.

• Il nome della categoria generata è uguale al nome del tag, ma senza il simbolo @ iniziale.

• È possibile filtrare e raggruppare i test da eseguire utilizzando queste categorie di unit test. Ad esempio, puoi contrassegnare i test cruciali con @important, quindi eseguire questi test più frequentemente.

Elementi di sfondo

L'elemento della lingua in background consente di specificare una precondizione comune per tutti gli scenari in un file di funzionalità

• La parte in background del file può contenere uno o più passaggi dello scenario che vengono eseguiti prima di qualsiasi altro passaggio degli scenari.

• SpecFlow genera un metodo dagli elementi in background che viene richiamato da tutti gli unit test generati per gli scenari.

Contorni dello scenario

Gli schemi dello scenario possono essere utilizzati per definire test di accettazione basati sui dati. La struttura dello scenario consiste sempre in una specifica del modello di scenario (uno scenario con segnaposto di dati che utilizzano la sintassi <placeholder>) e un insieme di esempi che forniscono valori per i segnaposto

• Se il framework di unit test lo supporta, SpecFlow genera test basati su righe dai contorni dello scenario.

• In caso contrario, genera un metodo logico di unit test parametrizzato per una struttura dello scenario e un metodo di unit test individuale per ogni set di esempi.

• Per una migliore tracciabilità, i nomi dei metodi di unit test generati sono derivati ​​dal titolo della struttura dello scenario e dal primo valore degli esempi (prima colonna della tabella degli esempi).

• È quindi buona norma scegliere un parametro univoco e descrittivo come prima colonna nel set di esempi.

• Poiché la sintassi di Gherkin richiede che tutte le colonne di esempio abbiano segnaposto corrispondenti nella struttura dello scenario, puoi persino introdurre una colonna arbitraria nei set di esempi utilizzati per denominare i test con maggiore leggibilità.

• SpecFlow esegue la sostituzione del segnaposto come una fase separata prima della corrispondenza delle associazioni di passaggio.

• L'implementazione ei parametri nelle associazioni di fase sono quindi indipendenti dal fatto che vengano eseguiti tramite uno scenario diretto o uno schema di scenario.

• Ciò consente di specificare in seguito ulteriori esempi nei test di accettazione senza modificare i collegamenti dei passaggi.

Commenti

È possibile aggiungere righe di commento ai file delle caratteristiche in qualsiasi punto iniziando la riga con #. Fai attenzione, tuttavia, poiché i commenti nelle tue specifiche possono essere un segno che i criteri di accettazione sono stati specificati in modo errato. SpecFlow ignora le righe di commento.