Come scrivere storie/scenari in BDD (Behavior Driven Design)

Question

Sto per utilizzare BDD (Behavior Driven Design) per la prima volta e sto cercando di abituarmi a questo diverso modo di affrontare un problema.

Puoi fornire alcune storie/scenari che dovresti scrivere per dire una semplice applicazione di login usando BDD?

Per esempio, da quello che ho letto, sembra che sia buono:

Quando un utente inserisce un invalido userid/password, quindi visualizzare un errore messaggio.

Al contrario di:

Convalida id e password attraverso la ricerca di un record corrispondente nel database .

Answer 1

Dan North ha alcuni consigli eccellenti su come scrivere storie. "Dan North- What's in a Story?"

Vorrei anche dare un'occhiata ad alcuni dei lavori eseguiti intorno allo Cucumber poiché hanno trascorso molto tempo a pensare a come scrivere queste storie in un modo comprensibile ed eseguibile.

Answer 2

L'articolo di Dan North che _Kevin ha menzionato è ottimo.

Ricorda, tuttavia, che esistono "storie utente", che in realtà dovrebbero essere scritte o almeno raccolte dal cliente/dagli utenti. Queste sono più delle storie di tipo "Come a, voglio, così".

Poi ci sono i criteri di accettazione, che identificano come e quando la user story sarà soddisfatta. È come quello che hai scritto nel tuo post: "Quando x, dovrebbe y".

C'è un sacco di sovrapposizioni qui con quelle che io chiamo "storie di sistema" nel mio sistema di gestione progetti e "specifiche" nei miei test che specificano comportamenti di cui l'utente potrebbe non essere a conoscenza, ma descrivono l'interazione tra le classi. Racconto di sistema: "Quando LoginHandler riceve un login e una password, deve convalidare i dati con un LoginValidator." Specification:

[TestFixture] 
public class When_the_login_handler_is_given_a_login_and_password 
{ 
    constant string login = "jdoe"; 
    constant string password = "password"; 
    static LoginValidator loginValidator; 

    context c =() => loginValidator = an<ILoginValidator>; 

    because b =() => sut.Validate(login, password); 

    it should_validate_the_data_with_a_LoginValidator = 
    () => loginValidator.was_told_to(x => x.DoValidation(login, password)); 
} 

Nevermind la sintassi di prova, si può vedere che il testo specifica stessa è incarnata nel nome classe di test e il nome del metodo. Inoltre, il test/specifiche sta effettivamente testando il comportamento delle classi. Quando test come questo passano per semplici storie di utenti, i criteri di accettazione sono stati soddisfatti.

Answer 3

ho trovato un discorso impressionante qui https://skillsmatter.com/skillscasts/2446-bdd-as-its-meant-to-be-done (attenzione, è necessario creare un account per visualizzare il video)