Durante a Mesa Redonda do DFTestes sobre “Implementar BDD ou ATDD é possível na realidade?“, percebi que BDD e ATDD são duas siglas pouco conhecidas pela comunidade de Teste de Software brasileira. Portanto, acabei decidindo fazer dois posts para explicar o básico de cada técnica. 🙂
Neste primeiro irei falar sobre BDD, cuja tradução é: Desenvolvimento Direcionado por Comportamento.
Como disse no começo, ambos são técnicas e técnicas para a equipe de desenvolvimento de software, não de teste. Acredito que esse seja o motivo principal, do desconhecimento por parte do pessoal da área de Teste de Software dessas duas técnicas. Porém, é altamente recomendável o pessoal de teste também ter conhecimento sobre elas, uma vez que eles podem ajudar os desenvolvedores na implementação de tais técnicas,.
Mas antes de detalhar e dá algumas opiniões sobre BDD, vou contar um pouco de história.
Surgimento do BDD
Num certo dia, um tal de Dan North estava refletindo sobre as dificuldades dos programadores ao usar TDD:
- Saber por onde começar;
- O que testar e o que não testar;
- Até onde testar;
- Como chamar os testes;
- E entender porque um teste falha.
E essas dúvidas e mal entendimentos eram observados com uma certa frequência pelo nosso amigo Dan North.
Foi aí que o Dan North viu a necessidade de criar algo para apresentar TDD de uma maneira direta ao lado iluminado da força. Evitando todas as armadilhas que podem levar o jovem aprendiz a ser tentado pelo lado negro da força.
Dan North então respondeu essa necessidade com a criação do BDD, que possui três princípios básicos:
- Tudo é comportamento: A área de negócios e a de Tecnologia devem se referir para o sistema da mesma forma;
- Onde está o valor do negócio: Todo sistema deve ter comportamentos que sejam um verificador do valor para o negócio;
- Faça o suficiente: Analisar, projetar e planejar tudo de cima para baixo, evitando o detalhamento prematuro.
O BDD evoluiu a partir de práticas ágeis e foi desenvolvida para tornar elas mais acessíveis e eficazes para os times que estão iniciando a entregar software de forma ágil. Com o tempo, o BDD cresceu para abranger também a análise ágil e a automação dos testes de aceitação.
Mas afinal o que é BDD?
Em poucas palavras, o BDD é uma técnica de desenvolvimento de software, onde os programadores desenvolvem o software direcionados por comportamentos. Tais comportamentos são a nível de negócio e ajudam o programador a entender melhor a funcionalidade que será desenvolvida.
Além disso, várias ferramentas (ex.: JBehave e Cucumber) permitem ao programador transformar esses comportamentos em verificações automatizadas.
Melhorando a comunicação
A técnica de BDD confia no uso de um vocabulário bem específico e pequeno, com o objetivo de minimizar a falta de comunicação e garantir que TODOS (stakeholders, desenvolvedores, testadores, analistas e gerentes), não estão apenas na mesma página, mas também estão usando as mesmas palavras. BDD pode ser considerada uma Ubiquitous Language (“Linguagem Onipresente”).
Essa é a grande sacada do BDD, pois permite que todos os envolvidos no projeto possam utilizar da mesma fonte, os comportamentos, para a partir deles realizar o seu trabalho.
Comportamento?
Um comportamento é descrito através de uma história, cujo modelo é:
Como um [X]
Eu quero [Y]
Então [Z]
Onde:
- X- é a pessoa que será beneficiada;
- Y- é alguma funcionalidade
- Z- é o benefício ou valor da funcionalidade;
Esse é um modelo que foi criado pelo Dan e pelo Chris Stevenson. E foi evoluído por eles para algo mais flexível para não ser artificial ou restrito aos analistas e estruturado o bastante para que as histórias possam ser quebradas e possam ser automatizadas. E aí a seguinte forma foi definida para definir um cenário, que está associado a uma história:
Dado algum contexto inicial (entradas),
Quando um evento ocorre,
Então verifique alguns resultados.
hmmm… isso me parece com algo
Sim, se parece com um caso de teste não é?
Entradas, ações e resultado esperado. Essa é a estrutura básica de um caso de teste, e é também a do cenário, proposta pelo BDD. A diferença está nas palavras e forma descrita, afinal é bom lembrar que um caso de teste nem sempre é algo tão entendível para os clientes.
BDD na prática
Eu já utilizei um pouco o BDD usando o Cucumber. E para fechar o post deixo um exemplo de implementação do BDD com o Cucumber, mais a título de exemplo mesmo (não irei explicar como instalar, implementar as steps definitions, executar, etc quem sabe num próximo post). Acredito que com ele fique mais fácil para encaixar as ideias e conceitos apresentados anteriormente.
No Cucumber temos a seguinte nomenclatura básica:
- Funcionalidade: igual ao modelo de história elaborado pelo Dan e Steve;
- Cenário: igual ao cenário explicado anteriormente.
Um exemplo de fluxo de BDD seria: cliente defini a funcionalidade e cenários associados a ela > desenvolvedor entender a funcionalidade e cenários e implementar as steps definitions > desenvolvedor roda um comportamento, irá falhar > desenvolvedor implementar o código para o comportamento > desenvolvedor executa o comportamento, que deverá funcionar.
Lembrando que esse é apenas um exemplo de fluxo de BDD, a forma de implementação e pessoas envolvidas pode variar de empresa para empresa, mas o fluxo básico acaba sendo esse mesmo (elaborar e rodar o comportamento, que irá falhar > desenvolver o código para o comportamento > executar o comportamento, que deverá passar), ou seja, igual ao do TDD.
Abaixo um exemplo, mostrando uma funcionalidade e cenários associados a essa funcionalidade:
#language: pt
Funcionalidade: Gerenciar produtos
Para gerenciar produtos
Como um usuário
Eu quero criar, editar, apagar e visualizar produtos
Cenário: Visualizar os produtos
Dado eu tenho os produtos iPad, iPhone
Quando eu vou para lista de produtos
Então eu devo ver "iPad"
E eu devo ver "iPhone"
Cenário: Criar um produto
Dado eu não tenho produtos cadastrados
E que eu esteja na lista de produtos
Quando eu clico "New"
E eu preencho "Name" com "iPad"
E eu preencho "Price" com "499"
E eu aperto "Create"
Então eu devo ver "Product was successfully created."
E eu devo ver "iPad"
Cenário: Editar um produto
Dado eu tenho o produto iPad
E que eu esteja na lista de produtos
Quando eu clico "Edit"
E eu preencho "Name" com "iPhone"
E eu preencho "Price" com "199"
E eu aperto "Update"
Então eu devo ver "Product was successfully updated"
E eu devo ver "iPhone"
Cenário: Apagar um produto
Dado eu tenho os produtos iPad, iPhone
E que eu esteja na lista de produtos
Quando eu clico "Destroy"
Então eu não devo ver "iPad"
E eu devo ver "iPhone"
Saiba mais:
Alguns bons artigos em português:
Tradução do Danilo Sato do artigo original do Dan North.
Introduzindo Desenvolvimento Orientado por Comportamento (BDD)
Artigo do Ronaldo Melo Ferraz, onde ele faz algumas considerações sobre TDD e BDD.
Algumas considerações sobre TDD e BDD
Artigo do Urubatan, mostrando algumas diferenças entre TDD e BDD e também o Cucumber.
Cucumber e BDD – Vantagens para a empresa (Argumentos para o gerente, para o arquiteto, para o presidente da empresa, …)
Fique por dentro das novidades, assine o feed do QualidadeBR.
Fonte:
http://behaviour-driven.org/
http://blog.dannorth.net/introducing-bdd/
O modelo deveria ser flexível o suficiente para não parecer artificial ou restritivo para os analistas, porém estruturado o suficiente para que pudéssemos quebrar as histórias em pedaços que pudessem ser automatizados. Nós começamos a descrever os critérios de aceitação com base nos cenários, da seguinte fo
QualidadeBR 