BDD: Introduzione

8

Sto iniziando con BDD e questa è la mia storia:

Feature: Months and days to days
    In order to see months and days as days
    As a date conversion fan
    I need a webpage where users can enter
    days and months and convert them to days.

Ho dei dubbi ...

Devo scrivere i miei scenari prima di scrivere qualcosa o prima dovrei scrivere uno scenario e poi scrivere il codice, scrivere di nuovo uno scenario e poi scrivere il codice, e così via ...?

Se dovessi scrivere prima i miei scenari, i miei passaggi possono essere approvati e il codice di produzione non viene ancora completato?

Quando devo eseguire il refactoring sul mio codice? Dopo che la funzione è stata completata o dopo l'implementazione di ogni scenario?

    
posta thom 08.07.2011 - 22:05
fonte

3 risposte

7

Dalla storia, deduco che stai codificando da solo.

Normalmente lo scopo di BDD è di abilitare le conversazioni, in particolare tra l'azienda e gli sviluppatori, in modo che il team possa essere certo di aver raggiunto una comprensione comune. Ci piace anche includere i tester, perché possono individuare quando abbiamo perso gli scenari.

Se lo fai da solo, prendi un'anatra di gomma e spiega il comportamento della tua applicazione all'anatra. Fornisci alcuni esempi di come dovrebbe funzionare. Questi saranno i tuoi scenari.

Per cominciare, vorrei suggerire non di automatizzare quegli scenari. Puoi scriverli se vuoi. Ricorda che i risultati di business che hai condiviso con l'anatra sono all'incirca nel livello giusto per esprimerli. Dovresti ora avere un'idea di come si comporta l'app e puoi eseguire manualmente gli scenari. Mi piace trattare tutto ciò che non funziona ancora come un bug . I ho a volte iniziato con l'automazione, ma solo quando conosco molto bene il funzionamento del sistema, ho familiarità con gli strumenti e l'interfaccia utente è ben compresa. Anche così spesso devo rielaborarlo un po 'quando ho scritto il codice.

Ad un livello inferiore, dì al tuo papero come si comporterà ogni classe. Fornire alcuni esempi. Le paperelle di gomma sono perfettamente in grado di comprendere il linguaggio tecnico. Ora hai il tuo BDD a livello di unità, alias test di unità. Il ciclo red-green-refactor avviene qui. (Non tendo più a dover rifattorizzare di più, perché sto pensando alle responsabilità delle mie lezioni, a formularle in un linguaggio orientato al business, e comunque tende a ricadere in un modo abbastanza bello. Lo faccio da un po 'di tempo ormai. Va bene se lo fai.)

Non rifattalo troppo. Vogliamo ancora ottenere un feedback sul nostro codice, perché c'è sempre cose che non sappiamo che non facciamo " so . La perfezione è il tuo nemico qui. Rendilo buono, rendilo leggibile, poi vai avanti. Se hai bisogno di fare qualcosa di perfetto per apportare ulteriori modifiche, fallo quando apporti ulteriori modifiche.

Se hai l'opportunità di avere un riscontro sui tuoi scenari da parte degli stakeholder aziendali, ma non sono con te, puoi inviare loro degli scenari non appena li hai scritti e prima di automatizzarli. Potresti anche voler inviare un modello dell'interfaccia utente, in modo che possano correlare le parole alle azioni. Non andare troppo avanti rispetto alla codifica con questo. Lavora partendo dal presupposto che ciò che hai già fatto è sbagliato e devi ottenere un feedback per scoprire come.

Come ultimo suggerimento, generalmente non esprima storie dal punto di vista di un utente (scenari, sì, ma non storie). Non sono user story. Probabilmente dovrebbe leggere qualcosa del tipo:

In order to attract people to my website
As @thom
I want users to easily convert months and days to days.

C'è comunque un obiettivo di livello più alto che stai cercando. Ciò ti aiuterà anche a sfruttare le capacità di cui hai bisogno. Buona fortuna e scuse per il post extra lungo.

    
risposta data 30.07.2011 - 10:56
fonte
3

Should I write my scenarios before coding anything or should I first write a scenario and then write code, write a scenario again and then write code, and so on ... ?

Entrambi funzioneranno. Sceglierne uno.

Non importa molto.

Più scenari hai, più design puoi fare in anticipo.

Più scenari hai, più tempo ci vuole per fare qualcosa.

When should I do refactoring on my code? After the feature is done or after each scenario implementation?

No. Si refactoring quando diventa difficile progettare lo scenario next .

    
risposta data 08.07.2011 - 22:07
fonte
3

Usa verbi descrittivi

Feature: CONVERT Months and days to days

Non prendere decisioni di progettazione nelle storie ["Ho bisogno di una pagina web" è una decisione di progettazione]

As a date conversion fan
I want to convert days and months into days

Utilizza gli obiettivi di valore aziendale nelle storie

So that [some business reason]

Scrivi quante più caratteristiche e storie possibili prima di iniziare a scrivere il codice; le storie si informano a vicenda , influenzano le funzionalità e ne informano il design.

Refactor dopo ogni storia. Rosso-Verde-refactoring.

    
risposta data 08.07.2011 - 23:34
fonte