Dalla storia, deduco che stai programmando da solo.
Normalmente lo scopo di BDD è consentire conversazioni, in particolare tra l'azienda e gli sviluppatori, in modo che il team possa essere sicuro di aver raggiunto un'intesa comune. Ci piace anche includere tester, perché possono individuare quando abbiamo perso scenari.
Se lo fai da solo, prendi un'anatra di gomma e spiega il comportamento della tua applicazione all'anatra. Fai alcuni esempi di come dovrebbe funzionare. Quelli saranno i tuoi scenari.
Per cominciare, suggerirei di non automatizzare quegli scenari. Puoi scriverli se vuoi. Ricorda che i risultati aziendali che hai condiviso con Duck sono al livello giusto per esprimerli. Ora dovresti avere un'idea di come si comporta l'app e puoi scorrere manualmente gli scenari. Mi piace trattare tutto ciò che non funziona ancora come un bug . A volte ho iniziato con l'automazione, ma solo quando so molto bene come funziona il sistema, ho familiarità con gli strumenti e l'interfaccia utente è ben compresa. Anche allora spesso devo rielaborarlo un po 'quando ho scritto il codice.
A un livello inferiore, dì alla tua anatra come si comporterà ogni classe. Fornisci alcuni esempi. Le papere di gomma sono perfettamente in grado di comprendere il linguaggio tecnico. Ora hai il tuo BDD a livello di unità, noto anche come unit test. Il ciclo del refattore rosso-verde avviene qui. (Non ho più bisogno di refactoring più di tanto, perché sto pensando alle responsabilità delle mie classi, esprimendole in un linguaggio orientato al business, e tende comunque a cadere in un modo abbastanza bello. Ma io lo sto facendo da un po 'di tempo. Va bene se lo fai.)
Non riformattare troppo. Vogliamo ancora ricevere feedback sul nostro codice, perché ci sono sempre cose che non sappiamo che non sappiamo . La perfezione è il tuo nemico qui. Renderlo abbastanza buono, renderlo leggibile, quindi andare avanti. Se devi apportare qualcosa di perfetto per apportare ulteriori modifiche, fallo quando apporti ulteriori modifiche.
Se hai l'opportunità di ottenere feedback sui tuoi scenari dagli stakeholder aziendali, ma non sono soddisfatti di 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 nella codifica con questo. Lavora con il presupposto che ciò che hai già fatto sia sbagliato e devi ottenere un feedback per scoprire come.
Come ultimo suggerimento, generalmente non formulare storie dal punto di vista di un utente (scenari, sì, ma non storie). Non sono storie utente. Dovrebbe probabilmente 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 qualche obiettivo di livello superiore che stai cercando. Questo ti aiuterà anche a trarre le capacità di cui hai bisogno. Buona fortuna e scuse per il post extra lungo.