BDD: Introdução

Estou começando com o BDD e esta é a minha história:

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.

Tenho algumas duvidas ...

Devo escrever meus cenários antes de codificar qualquer coisa ou devo primeiro escrever um cenário e depois escrever código, escrever um cenário novamente e depois escrever código e assim por diante ...?

Se eu escrever meus cenários antes, minhas etapas podem ser aprovadas e o código de produção ainda não foi concluído?

Quando devo refatorar meu código? Depois que o recurso é concluído ou após a implementação de cada cenário?

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.

Devo escrever meus cenários antes de codificar qualquer coisa ou devo primeiro escrever um cenário e depois escrever código, escrever um cenário novamente e depois escrever código e assim por diante ...?

Ambos irão funcionar. Escolha um.

Não importa muito.

Quanto mais cenários você tiver, mais design poderá fazer com antecedência.

Quanto mais cenários você tiver, mais tempo levará para fazer algo.

Quando devo refatorar meu código? Depois que o recurso é concluído ou após a implementação de cada cenário?

Não. Você refatora quando fica difícil projetar o próximo cenário.

Use verbos descritivos

Feature: CONVERT Months and days to days

Não tome decisões de design em histórias ["Preciso de uma página da web" é uma decisão de design]

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

Use metas de valor comercial nas histórias

So that [some business reason]

Escreva o maior número possível de recursos e histórias antes de começar a codificar; as histórias se informam , influenciam os recursos e informam o design.

Refatorar após cada história. Refator Vermelho-Verde.