Behavior Driven Development
Behavior Driven Development é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software, relaciona-se com o conceito de verificação e validação. Foi originalmente concebido em 2003, por Dan North como uma resposta à Test Driven Development, e tem se expandido bastante nos últimos anos.
Imagem: NotExist · BY-NC-ND · Openverse
O Desenvolvimento Orientado a Comportamento (Behavior-driven development) ou BDD é uma extensão do Test-driven development: (Desenvolvimento Orientado a testes). Esse tipo de desenvolvimento faz uso de uma linguagem simples e de domínio específico (DSL). Essas DSLs convertem afirmações em linguagem natural estruturada em testes executáveis. O resultado é uma relação aproximada ao critério de aceitação para uma função e os testes usados para validar essa funcionalidade. Sendo assim, é uma extensão natural de TDD (Desenvolvimento Orientado a Testes). Em seu núcleo, BDD é sobre repensar a abordagem a teste de unidade e teste de aceitação com objetivo de evitar problemas que naturalmente surgem. Por exemplo, BDD sugere que o nome dos testes unitários sejam sentenças começando com um verbo ("deve" por exemplo) e deveria ser escrito na ordem de valor comercial. Testes de aceitação deveriam ser escritos usando o framework ágil padrão de uma história de usuário: "Como um [um papel ou função] eu quero [funcionalidade] para que [benefício]". O critério de aceitação deveria ser escrito em termos de cenários e implementados como classes: [[Dado-Quando-Então]| Dado [contexto inicial], quando [ocorre um evento], então [garante que algo acontece]].
Imagem: jurvetson · BY · Openverse
BDD é guiado pelos valores de negócios; que é o benefício trazido para o negócio no qual a aplicação está sendo produzida. A única maneira na qual o benefício pode ser percebido é através de interfaces de usuário para a aplicação, comumente (mas nem sempre) a interface gráfica de usuário. Da mesma maneira, cada trecho de código, começando com a interface de usuário, pode ser considerado como sendo um cliente de outros módulos de código no qual a interface é utilizada. Cada elemento de código provê algum comportamento, o qual em colaboração com outros elementos provê o comportamento da aplicação. A primeira parte de código de produção que os desenvolvedores que usam BDD implementam é a interface de usuário, pois dessa maneira os desenvolvedores podem se beneficiar com um feedback rápido para saber se a interface está adequada ou não. Através de código, e usando princípios de design e refatoração, desenvolvedores descobrem colaboradores para a interface de usuário, e posteriormente para cada unidade de código. Isso os ajuda a aderirem o princípio de YAGNI, desde que cada trecho de código de produção é requerido pelos negócios ou por outro trecho de código já escrito.
Imagem: wocrig · BY-SA · Openverse
Em BDD, um desenvolvedor, algum profissional do setor de qualidade ou até mesmo o cliente podem esclarecer os requisitos quebrando-os em exemplos específicos. Um exemplo de requisito de uma aplicação de vendas poderia ser: "Itens reembolsados ou substituídos devem ser retornados para o estoque". Esse requisito pode ser quebrado em dois exemplos de cenários, como:
Cenário 2: Itens substituídos devem ser retornados ao estoque
Cada cenário é um exemplo escrito para ilustrar um aspecto específico de comportamento da aplicação. Ao discutir os cenários os participantes se perguntam se a saída descrita sempre resulta daqueles eventos ocorridos no dado contexto. Isso ajuda a desvendar outros cenários e esclarecer os requisitos. Por exemplo, um especialista do domínio pode notar que itens reembolsados não são sempre devolvidos ao estoque e então reorganizar os requisitos para algo do tipo "Itens reembolsados ou substituídos devem retornar ao estoque a não ser que estejam defeituosos". Este, por sua vez, ajuda os participantes a melhorar os requisitos, levando a uma melhor estimativa de quanto tempo aqueles requisitos levarão para serem implementados.
Imagem: ITU Pictures · BY · Openverse
Os mesmos princípios de exemplos, usando contextos, eventos e resultados podem ser usados para guiar o desenvolvimento a nível de unidade. Os exemplos seguintes descrevem um aspecto do comportamento de uma lista: Exemplo 2: Listas com alguma coisa dentro não podem estar vazias Ambos exemplos são necessários para descrever o comportamento do método esta Vazia de uma lista e obter os benefícios do mesmo. Estes exemplos podem ser automatizados utilizando até mesmo algum framework de TDD. Em BDD cada exemplo é comumente encapsulado num único método de teste, onde o nome do método é a descrição completa do comportamento. Por exemplo, usando Java e JUnit 4, os exemplos acima se tornariam: Às vezes a diferença entre contexto, eventos e resultados pode ser mais explícita. Por exemplo: No entanto, o exemplo é fraseado. O efeito deve ser o de descrever o comportamento do código em questão. Por exemplo, a partir dos exemplos acima poderia ser gerado:
Imagem: ITU Pictures · BY · Openverse
Defensores de BDD alegam que o uso de "deve" (should) e "garantirQue" (ensureThat) em exemplos de BDD incentivam os desenvolvedores a questionarem se as responsabilidade que eles estão atribuindo aos seus objetos são apropriados, ou se elas podem ser delegadas ou movidas inteiramente para outros objetos. Um objeto que é mais simples que o código de colaboração e provê a mesma interface, porém com um comportamento mais previsível, pode ser injetado no código que precisa dele, e os exemplos de comportamento do código podem ser escrito usando estes objetos ao invés da versão de produção. Estes objetos podem ser criados manualmente ou usando um framework de mocks como Mockito, Moq, NMock, Rhino Mocks, JMock, EasyMock. Questionando responsabilidades dessa maneira, e utilizando dublês de teste para cumprir os papéis necessários para os objetos de colaboração, incentivam o uso de Interfaces Baseadas em Papéis. Isso também ajuda a manter o código de implementação dos objetos pequenos e com baixo acoplamento.
