BDD è scalabile per progetti di medie e grandi dimensioni?

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 i tuoi requisiti. Ma cercare di implementare questo processo in un grande prodotto (non un esempio di calcolatrice) mi ha mostrato che le cose possono diventare (o diventeranno) 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, ne vale davvero la pena BDD? Risolve un problema che altre tecniche non fanno!

Penso che una delle migliori risorse su BDD sia il libro Specification by Example . Spiega molto su come organizzare i test BDD e come dovrebbero essere scritti in modo che non causino così tante rilavorazioni quando cambiano i requisiti.

Se le cose diventano complesse o complicate nei test, probabilmente stai facendo qualcosa di sbagliato. È lo stesso con BDD e TDD. Scrivere buoni test è difficile e ci vogliono mesi per impararlo.

Potrebbe aiutare a rendersi conto che il focus di BDD sono le conversazioni . BDD è davvero uno strumento di analisi che fornisce alcuni test di regressione come un piacevole sottoprodotto.

Ho usato scenari a tutti i tipi di livelli nella conversazione; dall'identificazione di diversi stakeholder per vedere se è probabile che un rilascio sia ben accolto, a capire come dovrebbe comportarsi un modulo o una classe .

Ci sono un paio di suggerimenti e consigli che posso suggerire per renderlo più semplice.

Se non l'hai mai fatto prima, cambierà.

Tutto ciò che è nuovo nel dominio o nell'azienda è suscettibile di modifiche. Potresti realizzare di essere in questo spazio se stai parlando degli scenari, mettendoli in discussione e gli affari dicono "Oh, non ne sono sicuro." Questo è un buon segno per smettere di provare a fare BDD e aggiungere qualcosa per ottenere un feedback più veloce, per aiutare l'azienda a capire cosa vogliono. Una volta che le idee si sono stabilizzate, gli scenari possono essere scritti a posteriori.

Tutti i progetti hanno un aspetto nuovo, altrimenti non li faresti.

Se l'hai già fatto, è noioso.

Oltre ad aspetti nuovi e differenzianti , i progetti di solito presentano alcuni aspetti mercificati che sono simili a quelli già realizzati. Ad esempio, se stavo producendo un nuovo telefono cellulare, avrebbe comunque bisogno di effettuare chiamate. "Effettuare una chiamata" è uno scenario così noto che non avremmo bisogno di parlarne. Allo stesso modo, cose come "login" o persino "registrazione dell'utente" sono noiose.

Ove possibile, utilizzare le librerie per questi e quindi non sarà necessario scrivere scenari intorno a loro. Inoltre, fare gli altri bit prima - hanno un già-utenti registrati e capire cosa la registrazione di lui in per . È improbabile che queste aree cambino, quindi potresti essere comunque in grado di cavartela con i test manuali.

Se qualcuno lo ha già fatto, parlare attraverso gli scenari può aiutare.

C'è un po 'di tempo in cui abbiamo requisiti specifici del 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, attingere alle conoscenze di un esperto e garantire che il comportamento noto e prezioso venga acquisito.

Questo è il punto in cui BDD funziona meglio. Il mio consiglio è di scrivere gli scenari più interessanti nella parte superiore del file delle funzionalità (o wiki, se non si sta automatizzando) ed eliminare tutti gli scenari che sono duplicati o facili da dedurre di conseguenza.

Ove possibile, utilizzare gli scenari come esempi di come funziona l'applicazione . 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 unitario, che è molto più facile da mantenere e più veloce da eseguire.

Ulteriori letture

Se sei interessato a questo, ecco alcune cose che ho scritto che potrebbero aiutare.

BDD in grande

Cynefin per gli sviluppatori , che approfondisce queste tre aree

Le diapositive del mio tutorial , che sono tutte belle e annotate per te, e coprono anche l'intero stack.

L' autunno scorso abbiamo realizzato un progetto piuttosto complesso (complessità del dominio ) e posso onestamente dire che mettere il lavoro iniziale in BDD ha salvato il progetto. Ho visto una forte correlazione tra la complessità del dominio e i benefici del BDD.

Consentitemi di evitare 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 che quella rete di sicurezza ti faccia sapere quando hai infranto le specifiche. Trascorrere il tempo iniziale ed elaborare tutti gli scenari, scriverli e infine scrivere tutti i test per loro.

E quando torni più tardi cercando di dare un senso alle cose, avere quella specifica testabile ti salva la vita.

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

• TDD, si assicura che l'ambito sia ben definito. In questo modo, prima progetti i tuoi casi di test. Quindi imposta un'aspettativa per il pezzo di codice che dovresti scrivere.
• TDD è un modo per proteggere il tuo codice. Supponiamo di scrivere una funzione semplice e successivamente aggiungere alcune complesse condizioni di commutazione in questa stessa funzione. Domani, se qualcun altro vuole modificare questa funzione, può fare riferimento al caso di test. Se vuole cambiare la tua funzione, allora deve cambiare anche il test case (la maggior parte delle volte). Questo gli permette di capire che dietro a ciò che hai scritto c'era un ragionamento.
• 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, hai impostato le aspettative in anticipo. In tal modo, ti limiti a vagare troppo lontano dall'obiettivo.
• TDD ti consente di rilevare eventuali bug prima che il progetto diventi online. Ciò ha principalmente a che fare con la qualità dei casi di test scritti.

Contro:

• All'inizio, TDD può essere un po 'complicato. Molte persone non comprendono il concetto di test case 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 insignificanti.
• TDD deve essere preso con un pizzico di sale. A nessuno sviluppatore piace trascorrere del tempo su alcuni casi di test scritti da qualcun altro. Decifrare il significato del testcase a volte può causare un forte mal di testa.

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