Lo sviluppo orientato al comportamento riguarda la progettazione o l'analisi?

Question

Più leggo su BDD e su come dovrebbe essere migliorato TDD, più mi sembra tutto confuso. Ho trovato citazioni di esperti che affermano che si tratta di design, ma anche di altri esperti che affermano che si tratta di analisi.

Il modo in cui lo vedo attualmente è questo:

1) analisi: BDD

da wikipedia

  

Il risultato dell'analisi orientata agli oggetti   è una descrizione di ciò che è il sistema   funzionalmente richiesto da fare, nel   forma di un modello concettuale.

Quindi dopo BDD abbiamo i requisiti (storie e scenari). Ma non sono sicuro della parte del modello concettuale.

2) design: ad es. con strumenti come il design guidato dalla resonsibility utilizzando le schede CRC

3) codice: codifica del progetto, facoltativamente usa test (come quello che dicono su TDD fatto male, che trovo anche utile)

Sbaglio nel modo in cui lo vedo? Al momento ho problemi a vedere la foresta attraverso gli alberi.

Answer 1

In breve, ha a che fare con Analisi .

BDD è per "sviluppo guidato dal test di accettazione" - vale a dire per sapere se un sistema in prova si comporta come previsto per uno specifico scenario di storia dell'utente.

Quando ho lavorato con Jbehave, l'abbiamo usato a livello di user story e ancora facevamo "convenzionale". TDD per la gestione di collaborazioni tra singoli oggetti e tra sottosistemi.

In genere i sistemi aziendali utilizzano scenari BDD per descrivere il comportamento del dominio aziendale e non testare i piccoli dettagli di implementazione all'interno del sistema. Volete che gli scenari BDD siano presentati al livello di astrazione dell'esperto di dominio. Tali scenari non avrebbero molto senso per gli esperti di dominio e sarebbero molto fragili se descrivessero ogni piccolo dettaglio dell'implementazione.

Uno scenario BDD dice cosa il sistema dovrebbe fare per una user story ma non come lo fa.

Answer 2

BDD riguarda la scrittura di "specifiche eseguibili" o test di accettazione aka test black-box che, per definizione, accetta prospettiva esterna dell'oggetto di test per derivare casi di test .

Quindi BDD non può riguardare il design, BDD riguarda il test di funzionalità / storie / scenari, BDD è più vicino all'analisi.

Answer 3

BDD - Sviluppo guidato dal comportamento

Behavior = ..in the context of .. Sviluppo - ... nella costruzione di ...

Lo sviluppo in questo caso mi indica che l'analisi è stata eseguita e si sta implementando qualcosa che si trova nel contesto di un comportamento specifico.

quindi per rispondere alla domanda, credo che sia nel Design .

Answer 4

Penso che da un'architettura POV BDD riguarderebbe il design. Devo progettare un'applicazione in grado di fare qualcosa, che verrà successivamente utilizzata nei test di accettazione. Quindi, dal design di alto livello, voglio assicurarmi di progettare per i vari requisiti di comportamento, in modo da non sovrascrivere e limitare la duplicazione.

Aiuta a garantire che potremmo non aver bisogno di riprogettare poiché l'utente ha più tempo per pensare a ciò che effettivamente vuole vedere, come funzionerà l'applicazione.

Answer 5

BDD (o TDD del resto) non è circa nulla. È una tecnica (nel caso di BDD, più di un approccio) che supporta la progettazione dell'analisi e (così come quella fastidiosa fase di implementazione). Senti spesso la frase "rosso, verde, refactor" associato a TDD, e quindi si applica a BDD: crea il test e verifica che fallisca, fai passare il test aggiornando la base di codice, quindi rielabora il sistema in una forma migliorata mentre preservi i test di superamento.

Quindi BDD supporta l'analisi quando crei i test: dovresti descrivere il comportamento richiesto sotto forma di test o esempi. Supporta la progettazione quando si eseguono i test: alle decisioni di progettazione viene impedito di interrompere inavvertitamente il comportamento richiesto e può essere guidato dall'analisi. Ma non fa alcuna analisi o progettazione per te; devi ancora pensare. È un modo per assicurarsi che, durante le fasi di analisi e progettazione, non ti contraddica.

Answer 6

BDD e TDD hanno ancora di più un nome molto sfortunato perché in realtà non copre ciò per cui vengono utilizzati.

• Non vuoi scrivere test per ogni possibile caso angolare durante il tuo ciclo di sviluppo che è qualcosa che i tester dovrebbero prendere.
• Non vuoi regressioni e vuoi essere sicuro di scrivere il codice necessario per cancellare questa iterazione in modo da ottenere un risultato ripetibile
• Non devi fare progetti dettagliati all'inizio, ma piuttosto annotare alcuni requisiti che vuoi vedere finiti questa volta.

BDD / TDD uno qualsiasi dei 2 va bene se non scrivi una riga di codice prima di avere un po 'di codice che descrive il bit di codice che stai per scrivere. In questo modo entrerai in una zona.
Sebbene non ci sia prova che BDD / TDD migliorerà la tua velocità di sviluppo (molto probabilmente non lo farà), ridurrà notevolmente il numero di problemi che ricevi dopo aver rilasciato il software che è stato dimostrato.

BDD è un'evoluzione di TDD in cui TDD esercita la pressione per testare tutto ciò che BDD rilassa e dice che dovresti testare solo il comportamento pubblico delle tue classi perché è probabile che gli interni cambino.

BDD riguarda tanto il design quanto l'analisi, ma non penso che sia la tua domanda, vero? Vuoi sapere come tradurre le storie in diagrammi di flusso e diagrammi architettonici?

Perché da quello che ottengo dalla tua domanda è che fai un grande progetto in anticipo e poi provi a codificarlo. Ciò non funzionerà con BDD perché, pur soddisfacendo le tue storie che dovresti scrivere in modo frammentario, ottieni automaticamente il codice e l'architettura. Si chiama design emergente, quindi non esiste un'enorme fase di pianificazione.

In uno SCRUM o come un sistema saggio questo funziona davvero bene perché l'azienda dà la priorità alle tue storie. Si parte dall'alto e si scrive una specifica / esempio per esso, quindi si tenta di soddisfare l'esempio ripetendolo fino a quando non si completa questo elemento di backlog e quindi si preleva quello successivo e si ricomincia da capo.

Spero che questo risponda alla tua domanda .. in caso contrario dovrai chiarire un po 'perché è un argomento più audace. In breve, BDD è puramente uno strumento di sviluppo, non per architetti, BA, ... I tester possono usare gli strumenti BDD ma spero che non sia l'unico strumento che stanno usando per testare l'applicazione.