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.