Desenvolvimento orientado por comportamento (BDD)

Executando o teste com JUnit4 neste ponto, o resultado será algo parecido com o ilustrado na Figura 3. Observe que as linhas dos cenários estão todas pendentes (“PENDING”). Isto acontece porque nenhuma linha de código está associada aos cenários ainda.

O próximo passo será adicionar um construtor à classe CaixaEletronicoTest, conforme a Listagem 6. Neste construtor, serão incluídos ao teste dois objetos do tipo Steps. Os Steps são classes que executam os cenários descritos no arquivo texto (veja a Figura 4). Neste exemplo, serão usados dois cenários, portanto dois steps. O nome das classes steps não faz diferença. Entretanto precisam ser instanciadas no início do teste pelo objeto principal (CaixaEletronicoTest). Veja o conteúdo dos Steps nas Listagens 7 e 8.

Entendendo os Steps do JBehave

Para criar um Step no JBehave é necessário estender a classe Steps (org.jbehave.scenario.steps.Steps). Cada método desta classe representa uma parte do cenário e estão conectados através das anotações: @Given, @When e @Then (veja o exemplo na Figura 5).

Na classe SaqueDeClienteEspecialComSaldoNegativo (exibida na Listagem 7), o método popularCliente() – linha 12 – instancia o objeto Cliente, define o saldo inicial e o tipo do cliente. O método sacar() – linha 18 – efetua o saque e armazena o resultado na variável saqueEfetuado para ser testada no método verificarOSaldo() – linha 23. Além disto, este método ainda verifica se o saldo do cliente foi alterado. Os valores de: saldoAtual – linha 12 – e valorDoSaque – linha 18 – são extraídos do arquivo texto e passados para os métodos através de expressões regulares (regex). A forma mais fácil de fazer isto é colocando as frases nas anotações idênticas às do arquivo texto, substituindo apenas os valores por variáveis. Veja um exemplo na linha 11.

O comportamento da classe SaqueDeClienteComumComSaldoNegativo (Listagem 8) é muito parecido com a anterior. A única diferença é que o cliente não pode efetuar o saque. Desta forma, o método sacar() – linha 19 – retorna uma exceção contendo uma mensagem para ser testada no método verificarOSaldo() – linha 27.

Para finalizar, execute o teste novamente usando o JUnit4. Se for exibida uma barra verde significa que o teste passou, caso contrário verifique o código e tente novamente. O resultado deve ser algo como o ilustrado na Figura 6.

Vantagens na utilização do JBehave

O fato de JBehave ter sido o primeiro framework para criação de testes orientado a comportamento, o fez ser o mais popular dentre os demais do mesmo gênero. Entretanto, isto também se deve às seguintes vantagens que ele apresenta:

• Totalmente desenvolvido em Java, o que facilita a integração com outros projetos da mesma plataforma;
• Os usuários podem especificar e executar as Estórias de usuário baseadas em arquivo texto;
• Anotações (@annotations) que conectam os textos da estória do usuário com os parâmetros dos métodos;
• Além do console, os resultados dos testes podem ser vistos ainda nos formatos: HTML, TXT e XML. Mas isto requer uma configuração específica que pode ser encontrada na documentação do framework;
• Controle de todas as etapas (métodos) dos cenários pendentes para que não fiquem sem ser implementadas;
• Localização das Estórias através de palavras chaves, podendo assim, serem escritas em qualquer idioma (exceto Given, When e Then);
• Integração com as principais IDEs, entre elas: Eclipse e NetBeans;
• Execução com ANT e Maven.

EasyB

O EasyB é um framework para BDD baseado em Groovy. Como o próprio nome sugere, EasyB é uma das formas mais fáceis de escrever testes orientado a comportamento. Tem como grande vantagem a sintaxe Groovy, o que o torna ágil e fácil de aprender.

As principais diferenças entre EasyB e JBehave estão na sintaxe do código e na forma que a estória é integrada ao teste. Enquanto o JBehave faz a conexão dos textos aos métodos automaticamente através de anotações, o EasyB não faz nenhum tipo de associação dinâmica, ou seja, ou textos são meramente usados para efeito de documentação. Além disso, os cenários não são escritos em um arquivo texto e sim no próprio corpo da classe.

Escrevendo testes com EasyB

Antes de começar o exemplo, baixe o framework (veja o endereço na seção Links) e adicione-o ao seu projeto. Caso utilize o Maven, adicione o conteúdo da Listagem 9 nas dependências do arquivo POM.xml.

Para aplicação dos exemplos com EasyB, será usado a mesma estória e cenários da Figura 2. O conteúdo da classe que representa o cliente está na Listagem 2. Como se pode observar, os testes podem ser escritos em formato de estória, conforme a Listagem 10. Neste caso, para serem reconhecidos pelo framework, devem estar com a extensão .story.

No EasyB, nem todos os elementos de uma estória são obrigatórios. A descrição – linha 1 – e a narrativa – linha 2 – servem apenas para documentação e não fazem efeito no código. Contudo, se utilizados, devem empregar as palavras chaves: description (descrição), narrative (narrativa), as_a (como um), i_want (eu gostaria) e so_that (para que). Note que, diferente do JBehave, os cenários foram colocados no mesmo arquivo, o que torna o código mais legível.

Para demonstrar este teste, criamos a classe CaixaEletronico.story com três métodos. O primeiro deles, before_each – linha 8, Listagem 10 –, é responsável por instanciar o objeto que representa o cliente e criar a variável que irá armazenar o resultado do saque. Este método será executado uma vez antes de cada cenário. O segundo método – linha 14 – é composto por blocos que funcionam com se fossem funções. Os blocos do EasyB são equivalentes às anotações do JBehave, inclusive as palavras chaves são as mesmas: given, when e then. Por mais incrível que pareça, as poucas linhas deste método fazem a mesma coisa que a classe SaqueDeClienteEspecialComSaldoNegativo do JBehave (exibida na Listagem 7), com a diferença que o EasyB não usa o Assert do JUnit para fazer as validações, pois tem uma função validadora específica chamada shouldBe – linha 23. O terceiro método é muito parecido com o segundo e tem o mesmo comportamento da classe SaqueDeClienteComumComSaldoNegativo (Listagem 8).

Para executar o teste acima, pode-se usar o Maven ou Ant. Entretanto, caso prefira, recentemente foi criado um plugin para o Eclipse (para mais informações, acesse o endereço em Links) que exibe o resultado no console (veja na Figura 7).

O EasyB ainda proporciona uma forma mais agradável de testadores e analistas visualizarem o resultado dos testes através de relatórios HTML, que ocultam o código, exibindo apenas detalhes de negócio. Veja um exemplo na Figura 8. Este tipo de relatório é gerado automaticamente quando o teste é executado pelo Maven (Figura 9). Para isso, basta acrescentar o conteúdo da Listagem 11 no POM.xml e colocar a classe de teste no pacote src/test/easyb.

Outra forma de escrever testes no EasyB é através de especificações. Neste caso, a extensão da classe deve ser .specification.

Para entender melhor este formato, observe o exemplo ilustrado na Listagem 12. Note que ele foge um pouco dos exemplos anteriores. Isto porque, não faz muito sentido escrever a estória da Figura 2 em forma de especificações. Neste caso, vamos apenas incluir e retirar elementos de um objeto do tipo Stack (pilha) para demonstrar a sintaxe deste formato. Observe que cada método é iniciado com a palavra-chave “it”. O nome dos métodos pode ser escrito em forma de frase e em qualquer idioma. O primeiro método, before – linha 2 –, será executado uma vez antes de cada método. Assim como nos exemplos anteriores, este método será responsável por inicializar todos os recursos em comum do teste. No segundo método – linha 5 –, inserimos um elemento na pilha e depois verificamos o tamanho dela. No terceiro método – linha 9 –, tentamos retirar um elemento de uma pilha vazia para exemplificar o tratamento de exceções usando a função ensureThrows() – linha 10. Por fim, no quarto e último método – linha 14 –, empilhamos uma série de elementos e em seguida verificamos a existência deles na pilha.

Para finalizar, basta executar o teste usando o plugin do EasyB. O Eclipse exibirá, no console, uma linha para cada método com o resultado do teste.

Vantagens na utilização do EasyB

O EasyB foi desenvolvido para facilitar o dia-a-dia dos programadores Java com a criação de testes orientados a comportamento. As principais vantagens deste framework são:

• Utiliza a linguagem Groovy, que possibilita a escrita de código com muito mais produtividade;
• Possui dois formatos de teste. A possibilidade de escrever o código em forma de estória ou especificação torna o EasyB uma boa alternativa para equipes que trabalham ou não com Estórias de Usuário;
• Possui plugin para o Eclipse, o que facilita a criação de testes nesta IDE;
• Os testes podem ser executados com Maven ou Ant;
• Fácil de aprender;
• Gera relatórios em HTML usando o Maven.

Spock

Spock é um framework de testes de especificações para aplicações Java e Groovy. O que mais chama atenção neste framework é a facilidade de aprendizagem e a alta expressividade do código, tornando-o assim, o passo mais curto para um desenvolvedor Java migrar para BDD usando uma linguagem dinâmica. Isto significa que para criar testes com Spock o desenvolvedor precisa ter noções de Groovy.

Por ser executado com JUnit4, o Spock é compatível com quase todas as IDEs existentes, ferramentas de build e servidores de integração contínua. Ele foi inspirado nos frameworks JUnit, JMock e RSpec, e nas linguagens dinâmicas Groovy e Scala. É uma mistura de tecnologias que deu certo.

O ciclo de vida de um teste Spock pode ser definido em quatro métodos:

• def setup(): executado antes de cada método. É compatível com a anotação @Before do JUnit. Neste método criam-se todos os recursos (objetos, variáveis, etc.) necessários para o teste;
• def cleanup(): executado depois de cada método. É compatível com a anotação @After do JUnit. Neste método eliminam-se todas as fixtures utilizadas para o teste;
• def setupSpec(): executado uma vez antes do primeiro método. É compatível com a anotação @BeforeClass do JUnit;
• def cleanupSpec(): executado uma vez depois do último método. É compatível com a anotação @AfterClass do JUnit.

No Spock, cada método é um cenário composto por até seis blocos: Setup, When, Then, Expect, Cleanup e Where. Nestes blocos, as descrições devem ser colocadas entre aspas duplas, podendo ser escritas em qualquer idioma. Neste aspecto, o Spock é muito parecido com o EasyB.

Praticando BDD com Spock

Antes de começar o próximo exemplo, baixe o framework Spock no endereço informado na seção Links. O pacote disponível para download contém um projeto de exemplo completo com Spock, Maven, Groovy e Gradle. Ou, caso prefira, adicione o conteúdo da Listagem 13 no POM.xml. Nesta listagem constam todos os plugins do Spock, inclusive o pacote completo do Groovy. Caso deseje saber mais sobre as dependências deste framework e personalizar o seu projeto consulte o site do Maven.

Gradle: É um sistema de build baseado em Groovy que trás a expressividade desta linguagem para o mecanismo de build, o que torna os scripts muito mais legíveis e fáceis de escrever. Ele é um grande “concorrente” do Ant e tem conquistado muitas equipes de desenvolvimento porque dispensa extensas configurações em XML. Tudo pode ser feito usando a linguagem Groovy, gerando um código legível e fácil de entender. Para saber mais, veja o endereço do site em Links.

O exemplo a seguir será baseado na mesma estória usada nos exemplos anteriores (Figura 2), bem como na classe que representa o cliente (Listagem 2).

Para usar o Spock, recomenda-se que o projeto seja do tipo Groovy (versão 1.7 ou superior). Isto porque algumas IDEs têm dificuldade de compilar o código Groovy em um projeto Java. Para fazer a conversão, clique com o botão direito do mouse sobre o projeto e acesse a opção Configure. Em seguida, selecione Convert to Groovy Project (veja a Figura 10). O código não sofrerá alterações e continuará funcionando da mesma forma, já que o Groovy também interpreta código Java.

Neste exemplo, criaremos a classe CaixaEletronicoTest.groovy. O conteúdo dela pode ser visto na Listagem 14. À primeira vista, nota-se uma grande semelhança com a sintaxe do EasyB, mas repare que no Spock os métodos e variáveis são definidos com a palavra-chave “def” (linhas 5 e 11), que aliás é padrão do Groovy. Outra diferença está na forma de fazer as verificações. No EasyB se usa o método shouldBe(), já no Spock as verificações são booleanas, sendo true ou false (observe as linhas 18, 20, 29 e 32).

O primeiro método, setup() – encontrado na linha 7 –, é responsável por instanciar os recursos em comum do teste e é executado uma vez antes de cada cenário. Os outros dois métodos – encontrados nas linhas 11 e 22 – têm o comportamento idêntico aos do EasyB, respectivamente – linhas 13 e 26 da Listagem 10. As diferenças estão na sintaxe e na forma de capturar a exceção. Enquanto o EasyB usa a função ensureThrows(), o Spock usa a função thrown() – linha 31.

Para executar este teste, pode-se usar o JUnit4, Maven ou Ant. No entanto, os dois últimos requerem uma configuração específica. Para saber mais, consulte a documentação do framework. Neste exemplo, usaremos o JUnit4. Observe o resultado do teste na Figura 11.

Vantagens na utilização do Spock

Embora o Spock ainda não seja muito difundido na comunidade Java brasileira, ele tem se mostrado uma boa alternativa para equipes que querem começar com BDD utilizando uma linguagem dinâmica. Suas principais vantagens são:

• Utiliza a linguagem Groovy, que é sinônimo de produtividade para a equipe;
• Possui um formato para escrita de testes bastante intuitivo e fácil de ler.
• Usa JUnit4, portanto pode ser usado nas principais IDEs existentes;
• Pode ser executado com Maven ou Ant;
• Assim como no EasyB, os cenários podem ser escritos na mesma classe;
• Pode ser usado para fazer testes de aceitação e integração.

Conclusão

Como se pode perceber, utilizando BDD não só melhoramos a comunicação entre desenvolvedores e testadores que passam a trabalhar em conjunto, mas também tornamos o desenvolvimento muito mais objetivo. Além do mais, se a empresa adotar o costume de escrever todos os cenários antes de iniciar a codificação dos testes, fica fácil entender o que o software deve fazer antes de implementá-lo, já que todos os envolvidos possuirão uma visão geral do projeto.

As equipes ágeis que utilizam Estórias de Usuário serão muito mais produtivas se usarem o conteúdo dos testes descritos no verso do cartão para criarem os testes. Isto porque, na prática, é o que o testador irá executar quando o software for finalizado. No entanto, mesmo as equipes que não utilizam estas técnicas podem usufruir dos benefícios de BDD, posto que, geralmente os testadores e analistas de negócio sempre sabem o que esperam do software antes dele ser desenvolvido.

Outro grande benefício que as equipes têm usando BDD é a documentação. Já que alguns frameworks disponibilizam relatórios dinamicamente sem esforço adicional. E mesmo os que não geram relatórios, ainda têm um formato de escrita muito parecida com um documento.

Embora muitas equipes de desenvolvimento utilizem apenas teste unitário para “garantir” a qualidade do sistema, grande parte dos frameworks de BDD vão muito mais além. O EasyB e Spock, por exemplo, também são usados para fazer testes de integração e aceitação, cobrindo assim, quase todas as camadas de um sistema.

Ao usar BDD as equipes não devem descartar as práticas de TDD, pois a primeira é uma evolução da segunda. Se este erro for cometido, BDD não trará grandes proveitos para as equipes, pelo contrário, poderá diminuir drasticamente a cobertura de testes do sistema. Contudo, se usada de forma correta, as práticas de BDD trarão um novo olhar sobre testes para as equipes.

Confira também