Potrebbe aiutare a capire che l'attenzione di BDD è la conversazione . Il BDD è davvero uno strumento di analisi che fornisce alcuni test di regressione come un buon sottoprodotto.
Ho usato degli scenari a tutti i livelli di conversazione; dall'identificazione di diversi stakeholder per vedere se è probabile che un comunicato sia ben accolto, a elaborando come dovrebbe comportarsi un modulo o una classe .
Ci sono un paio di suggerimenti e suggerimenti che posso suggerire per semplificare la procedura.
Se non l'hai mai fatto prima, cambierà.
Qualunque cosa sia nuova per il dominio o l'azienda, è probabile che cambi. Potresti capire che sei in questo spazio se stai parlando attraverso gli scenari, interrogandoli , e l'azienda dice "Oh, non ne sono sicuro". Questo è un buon segno per smettere di provare a fare BDD e spike qualcosa per ottenere un feedback più veloce, per aiutare l'azienda a capire che cosa vogliono. Una volta che le idee si sono stabilizzate, gli scenari possono essere scritti in retrospettiva.
Tutti i progetti hanno un aspetto che è nuovo o non li faresti.
Se lo hai già fatto, è noioso.
Oltre ai nuovi aspetti che differenziano , i progetti di solito hanno alcuni aspetti prodotti che sono simili a quelli già fatti. Ad esempio, se stavo producendo un nuovo telefono cellulare, avrebbe comunque bisogno di effettuare chiamate. "Effettuare una telefonata" è uno scenario così noto che non avremmo bisogno di parlarne. Allo stesso modo, cose come "login" o anche "registrazione utente" sono noiose.
Laddove possibile, usa le librerie per questi, e quindi non dovrai scrivere scenari attorno a loro. Inoltre, fai prima gli altri bit: hai già un utente già registrato e scopri cosa sta loggando in per . È improbabile che queste aree cambino, quindi potresti essere comunque in grado di superare i test manuali.
Se qualcuno lo ha già fatto, puoi parlare con gli scenari.
C'è un po 'tra cui abbiamo requisiti specifici per il dominio, cose che sono relativamente ben comprese da qualcuno , e dove la vera incertezza riguarda principalmente l'ambito piuttosto che il comportamento reale del sistema.
Parlare attraverso gli scenari può aiutare il team di sviluppo a scoprire comportamenti, ad attingere alle conoscenze di un esperto ea garantire che venga catturato il comportamento noto e prezioso.
Questo è il bit in cui BDD funziona meglio. Il mio consiglio è di scrivere gli scenari più interessanti nella parte superiore del file delle caratteristiche (o wiki, se non si sta automatizzando) ed eliminare qualsiasi scenario che sia duplicato o facile da dedurre come risultato.
Ove possibile, usa gli scenari proprio come esempi di come l'applicazione funziona . Ad esempio, se vuoi mostrare come funziona la validazione, mostra un paio di esempi di come l'applicazione aiuta l'utente a compilare un modulo. Verifica che la convalida sia rigorosa utilizzando il test delle unità, che è molto più semplice da mantenere e più veloce da eseguire.
Ulteriori letture
Se sei interessato a questo, ecco alcune cose che ho scritto che potrebbero aiutarti.
BDD nel grande
Cynefin per gli sviluppatori , che va più in dettaglio in queste tre aree
Le diapositive del mio tutorial , che sono tutte belle e annotate per te e coprono l'intero impilare troppo.