A partir da história, deduzo que você está codificando por conta própria.
Normalmente, o objetivo do BDD é permitir conversas, principalmente entre a empresa e os desenvolvedores, para que a equipe possa ter certeza de que alcançou um entendimento comum. Também gostamos de incluir testadores, porque eles podem detectar quando perdemos cenários.
Se você estiver fazendo isso por conta própria, pegue um pato de borracha e explique o comportamento do seu aplicativo ao pato. Dê alguns exemplos de como deve funcionar. Esses serão os seus cenários.
Para começar, sugiro não automatizar esses cenários. Você pode anotá-las, se quiser. Lembre-se de que os resultados de negócios que você compartilhou com o duck estão no nível certo para expressá-los. Agora você deve ter uma idéia de como o aplicativo se comporta e pode executar os cenários manualmente. Eu gosto de tratar tudo que ainda não funciona como um bug . I têm , por vezes, começou com a automação, mas só quando eu sei muito bem como funciona o sistema, eu estou familiarizado com as ferramentas e a interface do usuário é bem compreendida. Mesmo assim, muitas vezes tenho que reformular um pouco quando escrevi o código.
Em um nível mais baixo, diga ao seu pato como cada classe se comportará. Forneça alguns exemplos. Os patos de borracha são perfeitamente capazes de entender a linguagem técnica. Agora você tem seu BDD em nível de unidade, também conhecido como testes de unidade. O ciclo de refator vermelho-verde acontece aqui. (Eu não tenho mais necessidade de refatorar muito, porque estou pensando nas responsabilidades das minhas aulas, redigindo-as em linguagem orientada para os negócios e, de qualquer maneira, tende a cair de uma maneira bonita. Mas eu já faz isso há algum tempo. Tudo bem se você o fizer.)
Não refatorar demais. Ainda queremos receber feedback sobre o nosso código, porque sempre há coisas que não sabemos e que não sabemos . A perfeição é seu inimigo aqui. Torne-o bom o suficiente, deixe-o legível e siga em frente. Se você precisar fazer algo perfeito para fazer mais alterações, faça-o quando fizer mais alterações.
Se você tiver a oportunidade de receber feedback de seus negócios sobre seus cenários, mas eles não estiverem satisfeitos, você poderá enviar os cenários para eles assim que tiver escrito e antes de automatizá-los. Você também pode enviar um modelo da interface do usuário, para que eles possam correlacionar palavras com ações. Não fique muito à frente da codificação com isso. Trabalhe com a suposição de que o que você já fez está errado e precisa receber feedback para descobrir como.
Como uma dica final, geralmente não expresse histórias do ponto de vista do usuário (cenários, sim, mas não histórias). Eles não são histórias de usuários. Provavelmente deveria ler algo como:
In order to attract people to my website
As @thom
I want users to easily convert months and days to days.
De qualquer maneira, há alguma meta de nível superior que você está procurando. Isso também ajudará você a extrair os recursos necessários. Boa sorte e desculpas pelo post extra-longo.