MouseOver Studio

Um tempo atras quando conheci o Cucumber comecei a levar os testes a partir de estorias bem mais a serio. Na época eu olhava para minhas estorias e não me sentia contente com elas, sentia que não estavam legais. Foi por tal motivo que decidi pesquisar um pouco e obter dicas que me ajudassem a melhorar elas. Agora que tenho ganho mais experiencia, frequentemente vejo algumas estorias com os mesmos erros que eu já cometi, pelo que nesse post vou dar algumas dicas e recomendações para criar estorias melhores, me baseando no que li e aprendi no caminho.

Definir uma atividade especifica no título

Numa estoria descrevemos como uma funcionalidade gera algum tipo de valor para o cliente. No título definimos essa funcionalidade brevemente e ate a estoria não estar finalizada quer dizer que a funcionalidade não poderá ser realizada. Dado que diversas funcionalidades geram diferente valor para o cliente, não e legal juntar mais de uma funcionalidade numa estoria porque a finalização de uma funcionalidade estaria dependendo da finalização de outra.

Muitas estorias tem títulos como “Gerenciar artigos” onde nos cenários definem se a funcionalidade é uma adição, remoção e edição, por exemplo. Seguindo a teoria, ate não termos finalizado as trés funcionalidades, o usuário não iria poder gerenciar artigos. Acontece que nesse exemplo o usuário se importa mais com a adição de artigos, a única funcionalidade que já foi implementada. Se ela estivesse numa estoria separada, teríamos uma nova estoria finalizada e um nova funcionalidade já poderia ser entregue para o cliente.

E importante mencionar também que estorias mais simples e pequenas são mais fáceis de estimar, pelo que estorias muito grandes com muitas funcionalidades vão adicionar uma dificuldade nesse aspecto.

Definir estados nos cenários

Se nos títulos colocamos atividades, nos cenários colocamos estados. Supondo que as pessoas que acostumavam descrever as funcionalidades nos cenários vão seguir a primeira sugestão do artigo, vão poder ficar na duvida sobre o que por aqui. Nos cenários devemos descrever como o sistema devera se comportar quando exercer a função (título da estoria) num estado definido (título do cenário). Normalmente os cenários respondem à pergunta “Que acontece se …?”.

Imaginemos que temos a funcionalidade Efetuar pagamentos com cartão de debito. Temos entendido bem o que ira gerar valor para o cliente, mas como o sistema deve se comportar? Que acontece se a conta não tem mais dinheiro disponível? Que acontece se o cartão esta bloqueado? Que acontece se a conta tem dinheiro?

Essas trés ultimas perguntas tem definido trés cenários:

• a conta tem dinheiro
• a conta não tem dinheiro
• o cartão esta bloqueado

Não definir implementações

Ao não definirmos implementações nas nossas estorias vai ser muito mais fácil manter o foco no negocio ao invés da ferramenta. Tomemos como exemplo o seguinte cenário, onde a funcionalidade é registrar produtos:

Dado que visito a pagina de novos produtos
Quando preencho o formulário de novos produtos
E faço um click no botão 'registrar'
Então o numero de produtos existentes deve ser acrescentado por um

Esse cenário esta descrevendo mais o comportamento da ferramenta que do negocio em si. O que gera valor para o cliente não é preencher um formulário e poder clicar num botão, o que gera realmente valor e o que o cliente quer é registrar um produto. Sobre a página de novos produtos, ela não e parte do negocio, é parte da implementação.

Uma coisa que acabei de perceber agora é que muitos cenários acostumam descrever a primeira ação do cliente no passo Given ou Dado. Acho que isso ocorre porque esse passo é encarregado de definir um estado inicial ou contexto e como se esta pensando na implementação, o estado inicial poderia ser considerado a primeira interação do usuário com a ferramenta.

Mas como não devemos pensar na ferramenta e sim no negocio, no passo Given devemos indicar como estão as coisas antes das atividades do negocio. O passo Given tem relação direta com o título do cenário.

Acho que o cenário de exemplo ficaria melhor assim:

Dado que o numero de produtos é 2
Quando registro um novo produto
Então o número de produtos deve ser 3

O cenário fica simples porque o que gera valor é simples: registrar um produto. Os passos Given e Then (Então) podem ficar meio óbvios e desnecessários mas eles servem para preparar o teste (Given) e verificar se o teste deu certo ou não (Then). É bom manter esses dois passos também simples porque assim nossos testes ficam do mesmo jeito.

Mais informacão

Um post que me ajudou bastante no processo de melhorar minhas estorias foi este do Dan North, pai do BDD, muito recomendado. Nesse mês também saiu na revista Mundo Java um artigo muito legal do Rodrigo Yoshima falando sobre estorias, mais informação aqui.

Qualquer duvida ou discordância comigo por favor escreve-la nos comentários, acho muito legal conhecer os diferentes pontos de vista das pessoas.