Artigos Java BDD em aplicações Web
Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que se trata o artigo:

Utilização da metodologia BDD (Behavior Driven Development) para o desenvolvimento de aplicações web com as ferramentas JBehave e Selenium. O BDD descreve os comportamentos do sistema em uma linguagem compreendida por todos os envolvidos no projeto (cliente, desenvolvedores, equipe de QA, etc.) e possibilita automatizar os testes de aceitação em aplicações web.

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

Em equipes que utilizam ou pensam em utilizar metodologias ágeis no desenvolvimento de aplicações web. O BDD com essas ferramentas auxilia a documentação, comunicação e automação de testes de aceitação.

Resumo DevMan:

Este artigo apresenta o que é BDD, quais as vantagens de sua utilização e como as stories são descritas com essa metodologia. A seguir são discutidas as vantagens em utilizar as ferramentas JBehave e Selenium para descrever o comportamento de aplicações web e implementar testes de aceitação. Por fim, um exemplo passo-a-passo de como desenvolver uma aplicação web utilizando BDD é analisado.

Sem metodologias, o desenvolvimento de software é basicamente uma série de tentativas e erros. O desenvolvedor codifica, testa alguns cenários e corrige os problemas até que o sistema aparentemente funcione. Isso se repete até que o cliente solicite mais funcionalidades ou se depare com problemas na aplicação. Trabalhar dessa forma em sistemas simples pode até funcionar, porém em sistemas complexos torna o desenvolvimento caótico e compromete o custo, qualidade e prazo do projeto. Com o objetivo de resolver estes problemas, ao longo do tempo foram criadas metodologias baseadas em processos aplicados na engenharia, tentando adaptá-las para o desenvolvimento de software. Entretanto, na metade dos anos 90, essas metodologias começaram a ser questionadas, pois diversas pessoas as consideravam muito burocráticas. As principais consequências apontadas eram a lentidão no desenvolvimento e a dificuldade para responder às mudanças de plano, algo muito comum nessa área.

Em 2001 foi elaborado o Manifesto Ágil, um documento que define os fundamentos do desenvolvimento ágil de software baseado em doze princípios. Entre os princípios definidos pelo Manifesto Ágil, podemos destacar o foco na colaboração entre as pessoas e em artefatos que agreguem valor real para o cliente. O BDD (Behavior Driven Development ou Desenvolvimento Guiado por Comportamento) é uma metodologia que auxilia a equipe a colocar em prática esses dois conceitos através de uma linguagem ubíqua, a qual pode ser compreendida por todos os envolvidos no projeto. Essa linguagem é utilizada para descrever o comportamento do sistema e serve como base para a execução de testes automatizados. De forma simplificada, o ciclo do desenvolvimento com BDD é:

1. Descrever a story;

2. Detalhar o comportamento esperado da story através de cenários;

3. Mapear o cenário em uma classe de teste automatizado;

4. Implementar o código para que o teste passe com sucesso.

Story (ou User Story): Traduzido por alguns autores como Estória, é uma frase que representa uma funcionalidade do sistema utilizando o linguajar do dia-a-dia do cliente e/ou de negócios. No desenvolvimento ágil é muito utilizado em substuição de Casos de Uso.

Este ciclo deve se repetir para cada story até que todos os cenários especificados estejam contemplados. Dan North, criador do conceito Behavior Driven Development, classifica essa metodologia como a evolução do TDD (Test Driven Development) e do ATDD (Acceptance Test Driven Design). Apesar dessas duas metodologias também terem como requisito a implementação dos testes antes do código, o TDD é focado em testes unitários e o ATDD não possui uma linguagem padrão para a descrição das funcionalidades. No BDD, os comportamentos descritos seguem um formato padrão, por exemplo, Given/When/Then (Dado/Quando/Então), e são utilizados para testes de integração e/ou de aceitação.

TDD: Test Driven Development (Desenvolvimento dirigido por testes) é um conceito introduzido por Kent Beck em seu livro “Test-Driven Development”, publicado em 2003. Consiste em utilizar o ciclo “Testar > Codificar > Refatorar” de forma incremental com o objetivo de aumentar o controle do desenvolvedor sobre o código. Com essa técnica o feedback fica mais rápido, são evitadas arquiteturas complexas sem necessidade e o código fica mais limpo. Para se aplicar essa técnica em Java, geralmente utiliza-se um framework de teste unitário (JUnit, TestNG) e uma ferramenta para criação de mock objects (Mockito, JMock, EasyMock).

ATDD: Acceptance Test Driven Development (Desenvolvimento dirigido por testes de aceitação) é a utilização do conceito do TDD aplicado para testes de aceitação. Muitas ferramentas, como o Fit e o FitNesse, utilizam documentos, planilhas, wiki ou HTML para descrever os cenários de testes.

O artigo Desenvolvimento orientado por comportamento, publicado na Edição 91 da Java Magazine, explica com mais detalhes as diferenças do BDD em relação ao TDD e apresenta suas vantagens.

Alguns desenvolvedores também aplicam o formato Given/When/Then para testes unitários. A extensão BDD da biblioteca Mockito, por exemplo, permite criar mock objects utilizando este padrão.

A versão em português do Manifesto Ágil está disponível em http://manifestoagil.com.br.

Descrevendo a Story

Equipes que utilizam metodologias ágeis geralmente realizam uma reunião com o cliente e outros envolvidos para definir as stories do projeto. Apesar de existirem algumas variações, uma story basicamente descreve o motivo, a ação e o ator de uma funcionalidade do software na linguagem do cliente e/ou de negócio. A Figura 1 apresenta a story que será utilizada no exemplo deste artigo.

img

Figura 1. Exemplo de Story.

No BDD, essa story é detalhada em cenários que descrevem o comportamento esperado do sistema na visão do cliente ou usuário, como apresentado na Listagem 1. Veja que cada comportamento está descrito no formato Given/When/Then (Dado/Quando/Então), que é o formato utilizado por grande parte das ferramentas BDD. Assim a descrição possuirá um contexto inicial (Given), condições (When) e um resultado esperado (Then).

Geralmente esse detalhamento em cenários é realizado quando a story será implementada. No Scrum, por exemplo, isso pode ser feito durante a Reunião de Planejamento da Sprint. Somente quando o sistema estiver tratando todos os cenários descritos é que podemos definir a story como pronta.

Listagem 1. Cenários da Story no formato Given/When/Then.

Story: 
  Como usuário, quero calcular meu Índice de Massa Corporal (IMC) para saber meu grau de obesidade.
   
   
  Cenário: Índice para pessoa com peso normal
   
  Dado que usuário está na página principal, quando preenche o peso com 80, preenche a altura com 1,80 e clica em calcular, então deve ser exibida a página de resultado, o índice deve ser 24,69 e a situação deve ser “Peso normal”.
   
   
  Cenário: Índice para pessoa abaixo do peso
   
  Dado que usuário está na página principal, quando preenche o peso com 58, preenche a altura com 1,80 e clica em calcular, então deve ser exibida a página de resultado, o índice deve ser 17,90 e a situação deve ser “Abaixo do peso”.
   
   
  Cenário: Índice para pessoa acima do peso
   
  Dado que usuário está na página principal, quando preenche o peso com 100, preenche a altura com 1,80 e clica em calcular, então deve ser exibida a página de resultado, o índice deve ser 30,86 e a situação deve ser “Acima do peso”. ...

Quer ler esse conteúdo completo? Tenha acesso completo