BDD è scalabile per progetti di dimensioni medio-grandi?

22

In ogni sito web che leggi su BDD (Behavior Driven Development) trovi un esempio molto semplice che ti mostra quanto sia ovvio e facile definire le tue esigenze. Ma provare a implementare questo processo in un grande prodotto (non un esempio di calcolatrice) mi ha mostrato che le cose possono essere (o otterranno) piuttosto complesse e illeggibili; soprattutto cambiare le richieste in un secondo momento significa molto lavoro per correggere i test di integrazione per questo.

Quindi mi chiedo, BDD ne vale davvero la pena? Risolve un problema che altre tecniche non fanno!

    
posta D.D 22.02.2013 - 11:24
fonte

4 risposte

6

Penso che una delle migliori risorse su BDD sia Specifica per Esempio libro. Racconta molto su come organizzare i test BDD e come dovrebbero essere scritti in modo che non causino molte modifiche quando i requisiti cambiano.

Se le cose si complicano o complicano eccessivamente nei test allora probabilmente stai facendo qualcosa di sbagliato. È lo stesso con BDD e TDD. Scrivere buoni test è difficile e ci vogliono mesi per impararlo.

    
risposta data 22.02.2013 - 14:44
fonte
5

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.

    
risposta data 24.02.2013 - 12:14
fonte
3

Nell'autunno scorso abbiamo costruito un progetto abbastanza complesso ( dominio di complessità ) e posso dire onestamente che l'inserimento del lavoro iniziale in BDD ha salvato il progetto. Ho visto una strong correlazione tra la complessità del dominio e i vantaggi del BDD.

Consentitemi di togliermi una cosa: testare regole aziendali complesse è difficile. La domanda è: vuoi provare a ricordare tutti gli scenari pazzi ogni volta che apporti una modifica, o vuoi quella rete di sicurezza per farti sapere quando hai infranto le specifiche. Passa il tempo in anticipo e risolvi tutti gli scenari, scrivili e infine scrivi tutti i test per loro.

E quando torni più tardi a cercare di dare un senso alle cose, avere le specifiche testabili è un salvavita.

    
risposta data 22.02.2013 - 19:25
fonte
1

BDD è un processo di sviluppo basato su TDD (Test Driven Development) Ecco alcuni dei pro e contro di TDD tratti dalla mia esperienza personale:

  • TDD, assicura che l'ambito sia ben definito. In questo modo, si progettano i casi di test prima. Quindi imposta un'aspettativa per il pezzo di codice che dovresti scrivere.
  • TDD è un modo per salvaguardare il tuo codice. Supponi di scrivere una semplice funzione e successivamente aggiungerai alcune condizioni di commutazione complesse in questa stessa funzione. Domani, se qualcun altro vuole modificare questa funzione, può riferirsi al caso di test. Se vuole cambiare la tua funzione, allora, deve cambiare anche il caso di test (la maggior parte delle volte). Questo gli permette di capire che c'era un ragionamento dietro ciò che hai scritto.
  • TDD consente uno sviluppo software più veloce. Ognuno di noi avrebbe affrontato questo problema durante la codifica. Iniziamo con un'idea. E lentamente perderne traccia. Finiamo per mettere pezzi di codice indesiderati per gestire alcuni scenari. In TDD, si impostano le aspettative in anticipo. In tal modo, ti limiti a vagare troppo lontano dall'obiettivo.
  • TDD ti consente di rilevare possibili errori prima che il progetto sia online. Questo ha principalmente a che fare con la qualità dei casi di test che sono stati scritti.

Contro:

  • All'inizio, il TDD può essere un po 'complicato. Molte persone non capiscono il concetto di un caso di test che guida lo sviluppo.
  • TDD, a volte può portare a enormi sforzi nella manutenzione. Questo ha a che fare con casi di test indesiderati o privi di significato.
  • TDD deve essere preso con un pizzico di sale. Nessuno sviluppatore ama passare il tempo in qualche caso di prova scritto da qualcun altro. Decifrare il significato del testcase a volte può causare un strong mal di testa.

Lavoro su un progetto con oltre 900.000 righe di codice. E continuo a seguire BDD. Una cosa importante che devi considerare è il numero di possibili errori che potresti cogliere solo a causa dei casi di test. Tra qualche anno, giurerai BDD!

    
risposta data 22.02.2013 - 12:23
fonte