Atenção: esse artigo tem um vídeo complementar. Clique e assista!

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."