De que se trata o artigo:

Neste artigo, veremos uma nova técnica para desenvolvimento ágil conhecida como Behaviour Driven Development (ou BDD). Mostraremos com exemplos práticos como BDD encoraja a colaboração entre desenvolvedores, setores de qualidade e pessoas de negócios em um projeto de software.


Para que serve:

BDD serve para criar testes e integrar regras de negócios com a linguagem de programação, focando no comportamento do software. Além disso, ainda melhora a comunicação entre as equipes de desenvolvimento e testes, aumentando o compartilhamento de conhecimento entre elas.


Em que situação o tema é útil:

Esta metodologia é útil em projetos de software ágeis, que são construídos em várias iterações e estão sofrendo alterações ao longo do seu ciclo de vida. Quanto maior o projeto, mais difícil será a comunicação. Entretanto, BDD propõe uma forma eficaz de resolver estes problemas.

Resumo DevMan:

Este artigo faz uma breve introdução ao Desenvolvimento Orientado por Comportamento e demonstra como aplicar esta técnica utilizando os frameworks JBehave, EasyB e Spock. Os exemplos foram criados de uma forma que permita ao leitor comparar estas ferramentas e escolher a mais adequada à realidade de sua equipe.

Quando se estuda Engenharia de Software, aprende-se que todo sistema tem um tempo de vida útil, e que uma série de fatores podem contribuir para aumentar ou diminuir este tempo: arquitetura, modelagem, tecnologia utilizada, aceitação do mercado, etc. No entanto, nenhuma empresa desenvolve um sistema pensando no dia em que ele deixará de atender as necessidades do seu cliente, apesar desta ser uma verdade certa.

Neste ciclo, o sistema passa a maior parte do tempo sofrendo alterações. E estas manutenções, sejam elas corretivas ou não, podem melhorar ou piorar o sistema, dependendo da forma que forem implementadas. Pensando neste e em outros problemas, Kent Beck apresentou ao mundo em 2003, através do seu livro “Test-Driven Development”, uma técnica para criar sistemas baseados em testes que visa garantir a qualidade e a funcionalidade do software durante este ciclo.

Embora TDD seja uma técnica testada e aprovada por grandes desenvolvedores ágeis, muitas equipes de desenvolvimento ainda caem em algumas armadilhas e mal-entendidos do tipo: por onde começar, o que testar e o que não testar. Isto sem falar que quem escreve os testes são os desenvolvedores, mas quando a equipe de qualidade vai testar, ela se preocupa com o comportamento do sistema e não com os testes unitários. Desta forma, não há comunicação eficiente entre as duas equipes no nível de código.

Para tornar a aplicação de TDD mais simples e ajudar as equipes de desenvolvimento a resolverem as questões mencionadas acima, surgiu o Behaviour Driven Development (BDD). Neste artigo, veremos como aplicar esta técnica de forma eficiente, utilizando os frameworks mais conhecidos da comunidade Java.

O que é TDD?

Test Driven Development(TDD) ou, em português,Desenvolvimento Dirigido por Testesé uma técnica dedesenvolvimento de softwareque se baseia em um ciclo curto de repetições. Primeiramente o desenvolvedor escreve umcaso de testeautomatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste. Posteriormente este código serárefatoradopara colocá-lo sob padrões aceitáveis.

Kent Beck declarou em 2003 que TDD encoraja designs de código simples e inspira confiança. Do ponto de vista de Robert C. Martin, escritor do livro “Agile Software Development”, o objetivo de TDD é a especificação e não a validação, ou seja, é a maneira de pensar através das necessidades do projeto antes de escrever o código funcional.

BDD, a evolução

BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Além disso, pode-se dizer também, que BDD é a evolução do TDD. Isto porque, os testes ainda orientam o desenvolvimento, ou seja, primeiro se escreve o teste e depois o código.

O foco em BDD é a linguagem e as interações usadas no processo de desenvolvimento de software. Desenvolvedores que se beneficiam destas técnicas escrevem os testes em sua língua nativa em combinação com a linguagem ubíqua (Ubiquitous Language). Isso permite que eles foquem em por que o código deve ser criado, ao invés de detalhes técnicos, e ainda possibilita uma comunicação eficiente entre as equipes de desenvolvimento e testes.

Linguagem Ubíqua: é uma linguagem estruturada em torno do modelo de domínio e usada por todos os membros da equipe para conectar todas as suas atividades com o software. Numa equipe de desenvolvedores são: os jargões técnicas, terminologias das discussões do dia-a-dia ou uma linguagem incomum para pessoas de outros departamentos.

A linguagem de negócio usada em BDD é extraída das estórias ou especificações fornecidas pelo cliente durante o levantamento dos requisitos. Alguns frameworks utilizam o conteúdo das estórias escritas em um arquivo de texto como cenários para os testes. Quando Dan North apresentou este conceito em 2003, ele sugeriu um padrão para escrita destes arquivos. Veja na Figura 1. Este é apenas um modelo, ou seja, não é obrigatório. Entretanto, Dan North denota que é extremamente importante a equipe seguir um padrão para facilitar a comunicação entre os envolvidos no projeto.

Figura 1. Modelo de escrita de Estória de Usuário em arquivo texto.

O primeiro framework de BDD, JBehave, foi criado por Dan North, seguido de um framework em Ruby chamado RBehave, o qual foi depois incorporado ao projeto RSpec. Ele também trabalhou com David Chelimsky, Aslak Hellesøy entre outros para desenvolver o framework RSpec e também escrever o livro “The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends”.

Vantagens em usar BDD

Quando Dan North fala sobre BDD, ele sempre esclarece que o propósito não é anular as práticas de TDD, muito pelo contrário, é adicionar a elas uma série de outras vantagens, dentre as quais se podem listar:

Comunicação entre equipes: na maioria das empresas de desenvolvimento de software é difícil fazer com que desenvolvedores e testadores trabalhem em conjunto para atingir um objetivo. BDD possibilita esta integração porque os testadores podem escrever os cenários de testes para os desenvolvedores implementarem;

Compartilhamento de conhecimento: com desenvolvedores e testadores trabalhando juntos, ao longo do tempo, um irá transferir o seu conhecimento para o outro, criando assim uma equipe multifuncional;

Documentação dinâmica: algumas equipes ágeis afirmam que não documentam o sistema porque a manutenção destes artefatos é custosa. Usando os frameworks de BDD estes artefatos são gerados dinamicamente sem nenhum esforço adicional. Alguns, inclusive, geram relatórios em formato HTML, o que irá facilitar uma consulta posterior;

Visão do todo: Fergus O’Connell, em sua obra “How to Run Successful High-Tech Project-Based Organizations”(Artech House, 1999), apresenta uma relação dos principais motivos que levamprojetos de software ao fracasso. O primeiro deles é: “os objetivos do projeto não são bem definidos e compartilhados entre todos os envolvidos”. Por este motivo, BDD sugere que os analistas/testadores escrevam os cenários antes mesmo dos testes serem implementados, e desta forma os desenvolvedores terão uma visão geral do objetivo do projeto antes de codificá-lo.

Não restam dúvidas de que desenvolver uma aplicação guiada por testes é uma prática extremamente benéfica. O resultado é um código de boa qualidade, alta coesão e com número reduzido de bugs, com isso proporcionando um prazo de validade longo e manutenções mais baratas no futuro. No entanto, iniciar no mundo dos testes não é nada fácil.

...
Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo