Quanto astratto dovresti ottenere con BDD

4

Stavo scrivendo alcuni test in Gherkin (usando Cucumber / Specflow). Mi stavo chiedendo in che modo astratto dovrei ottenere con i miei test.

Per non rendere questo open-ended, quale delle seguenti affermazioni è meglio per BDD:

Given I am logged in with email [email protected] and password 12345
When I do something
Then something happens

al contrario di

Given I am logged in as the Administrator
When I do something
Then something happens

Il motivo per cui sono confuso è perché 1 è più basato sul comportamento (archiviazione in e-mail e password) e 2 è più semplice da elaborare e scrivere i test.

    
posta Newton 30.05.2012 - 18:56
fonte

2 risposte

10

Non sono davvero test; sono scenari o esempi su come usare il tuo codice. Se eviti la parola "test" avrai un tempo più semplice, e diventerà ovvio che 2 è la via da seguire perché sarai in grado di discutere i tuoi scenari con il business.

L'azienda non ha interesse per i test formulati nel modo in cui hai descritto in 1. Gli uomini d'affari in genere preferiscono parlare piuttosto di un esempio di come usare il codice, che porterà inevitabilmente a 2.

Inoltre, il fatto che tu stia chiedendo ti suggerisce che non stai ancora parlando al business. Per favore vai ad avere le conversazioni. È il bit più importante del BDD, molto più importante dell'automazione, e ti farà risparmiare molto lavoro di rilavorazione e dolore, oltre a contribuire a mantenere gli scenari interessanti e manutenibili nel caso tu faccia automatizzarli.

Questo primo scenario non descrive il comportamento in modo diverso rispetto al secondo: descrive solo la meccanica del comportamento, che renderà più difficile cambiare quelle meccaniche in seguito, oltre a introdurre dettagli non necessari. L'unica volta che ti serve uno scenario formulato nello stesso modo di 1 è se sei davvero affascinato dal login. Preferirei vedere uno scenario incentrato sull'attività preziosa per il tuo business che stai loggando per .

    
risposta data 30.05.2012 - 21:39
fonte
0

Un'altra cosa fondamentale da considerare quando scrivi le tue caratteristiche e scenari è questa: se cambiamo X nel sistema, dovrò ridefinire i miei scenari? Se la risposta è sì, direi che si tratta di dettagli specifici. Le funzionalità e gli scenari IMO dovrebbero cambiare solo a causa di cambiamenti nei requisiti del business / stakeholder.

Quindi nei tuoi esempi: Supponiamo che tu cambi il sistema di autenticazione e imposti un nome utente anziché un indirizzo email come identificatore utente per l'accesso.

Nel tuo primo esempio dovrai tornare al tuo scenario e cambiarlo. Nel secondo esempio: non lo farai.

    
risposta data 31.05.2012 - 01:03
fonte

Leggi altre domande sui tag