Consultas e Validações: BDD com JBehave
BDD é uma técnica de desenvolvimento ágil de software que visa guiar a codificação e os testes a partir de aspectos comportamentais do sistema a ser desenvolvido. O JBehave é um dos frameworks que implementa esta técnica.
Envolve especialistas no negócio.
Estabelece uma linguagem comum para especificar e testar.
Padroniza o desenvolvimento dos testes.
IDE de desenvolvimento: Eclipse (download) + Plugin para Maven, o m2e (download).
Projeto de Exemplo: baixe aqui o fonte do projeto usado como exemplo neste post.
Considerando a seguinte user story:
Como administrador, Quero cadastrar usuários Para mante-los atualizados.
Esta user story reflete uma funcionalidade CRUD para gerenciamento da entidade usuário, o que requer testes de validação e consulta.
Considerando os seguintes cenários:
Cenário: Usuário válido deve ser salvo. Dado um usuário A com e-mail [email protected] Quando A for salvo Então A deve ser persistido pelo repositório. Cenário: Usuário sem e-mail não deve ser salvo. Dado um usuário B sem e-mail Quando B for salvo Então a obrigatoriedade do e-mail deve impedir a operação. Cenário: Usuário com e-mail inválido não deve ser salvo. Dado um usuário C com e-mail foo Quando C for salvo Então a validade do e-mail deve impedir a operação.
Nos cenários acima, encontramos as seguintes classes:
UsuarioService: serviço de gerenciamento de usuários.
UsuarioRepository: repositório de usuários.
Antes de ser persistido por UsuarioRepository, Usuario é validado por UsuarioService. Somente após garantir a integridade da entidade é que sua persistência é delegada para UsuarioRepository. Para este teste a lógica de persistência será mockeada.
Os cenários Usuário válido deve ser salvo, Usuário sem e-mail não deve ser salvo e Usuário com e-mail inválido não deve ser salvo garantem que Usuario só é persistido após passar pela validação.
Considerando o seguinte cenário:
Usuário é a entidade a ser consultada, enquanto UsuarioService é a classe que valida sua integridade. UsuarioService também integra com UsuarioRepository, sendo o primeiro responsável apenas pela validação, e encapsulando e abstraindo o segundo, este que é responsável pela persistência.
O cenário Consulta a usuários deve permitir filtro por nome garante que a consulta retornará o resultado esperado pelo cenário. Ele armazena os dados num banco em memória que só existe durante a execução dos passos:
O BDD estabeleceu não só as classes a serem criadas, como também a ordem de criação. Parte de uma user story, obtendo uma classe para cada critério de aceitação, os cenários. Nesses cenários são identificadas entidades, serviços e repositórios. Sendo assim, foi a necessidade do usuário, identificada pela user story, que direcionou quais classes, quando e porque devem ser criadas. É o desenvolvimento se aproximando do negócio e gerando somente componentes de software realmente pertinentes.