Qual è l'ambito di un Bdd Scenario in particolare quando si specificano le modifiche a un'applicazione esistente?

Question

Qual è l'ambito di un Bdd Scenario in particolare quando si specificano le modifiche a un'applicazione esistente?

#1 da (2 voti)

0

Lavoriamo con BDD da un po 'di tempo e un problema che continua a crescere è legato all'ambito dei nostri scenari. Soprattutto quando si tratta di apportare modifiche alle funzionalità esistenti.

Come sviluppatore vedo gli scenari come affini a una specifica, es. questo è il cambiamento che è richiesto. Tuttavia, spesso sembrano andare in regressione o test di accettazione.

Quindi lo scenario 2 non richiederà alcuna modifica al codice, ma potrebbe indicare una funzione che richiede anche il test a seguito di una modifica apportata dallo scenario 1 (test di regressione). Oppure lo scenario 2 potrebbe fornire un test alternativo alla stessa funzione dello scenario 1 (test di accettazione).

A prima vista questo non sembra irragionevole, tuttavia aumenta notevolmente il numero di scenari, il che richiede più tempo per scrivere e rende più difficile per gli sviluppatori vedere il legno per gli alberi.

Quale dovrebbe essere l'ambito degli scenari quando si apporta una modifica alla funzionalità esistente? Possiamo avere uno scenario che specifica una modifica in termini generici piuttosto che uno scenario separato per ciascuna funzione correlata?

bdd

posta Si Keep 01.07.2011 - 12:08

fonte

1 risposta

Leggi altre domande sui tag bdd

Progettazione di una gerarchia di classi gestibili per la rappresentazione di AST DDD: radici aggregate di sola visualizzazione, creazione di DTO e un problema di caricamento lento

score 2 · Accepted Answer

In generale, BDD dovrebbe rendere le cose facili da cambiare. Finché stai formulando i tuoi passi ad un livello sufficientemente elevato, gli scenari dovrebbero essere abbastanza semplici da gestire. Ecco i miei suggerimenti e suggerimenti per renderlo più efficace.

Dividi i tuoi scenari in aree funzionali - cose che condividono lo stesso "quando". Puoi usare questo per richiamare la differenza tra i contesti e i risultati che producono, così gli sviluppatori saranno in grado di vedere e capire la differenza più facilmente.
In qualsiasi luogo in cui la tua applicazione non stia cambiando, sposta questi scenari e falli correre da un giorno all'altro. Tutto ciò in cui l'applicazione non si è comportata male per un mese circa. Puoi riportarli nella build principale se uno di essi si rompe.
Concentrati sulle funzionalità e sui risultati aziendali, piuttosto che su passaggi individuali dell'interfaccia utente a grana più piccola. Ad esempio, se aggiungi una casella di conferma, dovresti solo cambiare l'automazione sottostante, non il modo in cui gli scenari sono formulati.

Hai ragione che gli scenari alla fine diventano test di regressione e test di accettazione. All'inizio, però, sono davvero lì per aiutare un team ad esplorare la loro comprensione di come il sistema dovrebbe comportarsi. Potrebbe essere sufficiente, in questo caso, dire "Dovrebbe comportarsi come < quest'altra cosa >" e lasciare la generazione degli scenari per dopo.

Generalmente, finché gli sviluppatori possono derivare gli scenari, qualsiasi modo di formulare il comportamento va bene. Non è necessario acquisire tutto in una forma scritta e certamente non devi preoccuparti di automatizzarlo mentre stai parlando di ciò che il sistema dovrebbe fare.