segunda-feira, novembro 17, 2008

Qualidade de software na prática com Behavior Driven Development e Acceptance Test Driven Development

Em um artigo anterior sobre qualidade interna e externa de software abordei a importância da testabilidade para a qualidade de um sistema. Reforçando a mensagem: quando você aumenta a testabilidade do software você diretamente melhora a sua arquitetura e o seu design. Desenvolver sem testes unitários automatizados e sem testes de aceitação é simplesmente já construir código legado desde o momento zero!

No artigo eu comentei sobre estratégias para melhorar a qualidade e a manutenibilidade, entrando brevemente no como fazer. Neste artigo vou falar mais do como fazer, tratando sobre técnicas de desenvolvimento de software modernas e ferramentas para apoiá-las: O Behavior driven development (desenvolvimento dirigido por comportamentos) e o Acceptance test driven development (desenvolvimento dirigido por testes de aceitação).

O behavior driven development foi inicalmente descrito por Dan North em seu artigo Introducing BDD. O BDD é similar ao Test Driven Development (TDD), mas é distinto em alguns pontos sutis, porém cruciais. Pelas convenções de TDD os métodos e classes de testes recebem nomes baseados nas classes de produção. BDD reorienta o foco para comportamentos do sistema. O BDD usa um template para se pensar no comportamento e nos testes do código:

Dado (Given) um contexto inicial

Quando (When) um evento ocorre

Então (Then) assegure alguns resultados.

O exemplo do artigo do Dan North é bem ilustrativo. Suponha a seguinte estória do usuário (user story):

Como um cliente, eu desejo sacar dinheiro da ATM, de modo que eu não precise gastar tempo na fila.

Como podemos saber quando essa estória está pronta (conceito de ‘done’)? Há vários cenários a se considerar. Alguns exemplos: conta tem crédito, a conta não tem mais limite de crédito. Usando o template acima o cenário 1 seria esse:

Cenário 1: Conta tem crédito

Dado que a conta possui crédito

E o cartão é válido

E a dispensadora contém dinheiro

Quando o cliente requisitar dinheiro

Então assegure que a conta seja debitada

E assegure que o dinheiro é dispensado

E assegura que o cartão é retornado.

O que isso muda em nossos testes unitários? Muda porque podemos usar uma ferramenta como o JBehave para desenvolver os testes no formato Dado / Quando / Então (Given / When / Then). O teste unitário fica voltado para os comportamentos e não mais para testar simplesmente métodos.

Porém, para equipes experientes e já acostumadas com TDD talvez essa mudança seja impactante. Para equipes novas seja mais complexo que um teste unitário simples. Por isso, a meu ver, o maior ganho do Behavior Driven Development está quando ele é unido com a técnica de Acceptance Test Driven Development (ATDD).

Segundo Koskela, em seu livro “Test Driven: Practical TDD and Acceptance TDD for Java Developers”, o TDD puro ajuda os desenvolvedores de software a produzir código de maior qualidade e manutenibilidade. O problema é que clientes raramente estão interessados em código. Eles querem sistemas que os tornem mais produtivos e gerem retornos sobre os investimentos. O ATDD ajuda a coordenar projetos de software de forma a entregar o que o cliente deseja.

Os testes de aceitação são especificações do comportamento e funcionalidade desejados para um sistema. Eles nos informam como, para uma determinada estória de usuário ou caso de uso, o sistema trata determinadas condições e entradas. Novamente conforme Koskela, um bom teste de aceitação deve ser:

- Propriedade dos clientes

- Escrito em conjunto com clientes, desenvolvedores e analistas de testes

- Sobre o O Que e não sobre o Como.

- Expresso na linguagem do domínio do problema

- Conciso, preciso e sem ambigüidades.

Até aqui fizemos uma descrição de um teste de aceitação que poderia simplesmente estar dentro de um documento Word ou planilha Excel. Então qual é a diferença do teste de aceitação tradicional para o teste de aceitação “clássico”? Primeiro é que no ATDD o teste deve ser automatizado. Esse é um ponto essencial para realizar testes regressivos contínuos. Em segundo lugar, os testes de aceitação são escritos ANTES da funcionalidade. Mas como? Seguindo os passos abaixo:

- Pegar uma estória ou fluxo de caso de uso

- Escrever os testes de aceitação na linguagem do domínio do cliente

- Automatizar os testes de aceitação

- Implementar funcionalidade.

É claro que ferramentas direcionadas para o ATDD ajudariam. Temos diversas open source no mercado como, por exemplo:

- Fitnesse

- Selenium

- Exactor

- TextTest

E por fim, a mais interessante e que vou comentar mais um pouco: Concordion.

O que você acharia se tivesse uma ferramenta que pudesse ler uma especificação de um caso de uso, de uma estória ou de um teste de aceitação escrito em linguagem comum e executasse esses passos em seu sistema automaticamente? Pois é, essa ferramenta existe, é open source e seu nome é Concordion. Ela é um framework que permite transformar uma descrição de requisitos em português em um teste automatizado, algo conhecido como especificação ativa. Portanto, uma especificação que se torna ainda mais útil porque a partir dela podemos executar testes automatizados!!!

Como ela funciona? Basicamente se escreve a especificação em um HTML simples, com comandos escondidos que definem o comportamento dos testes. A instrumentação dessa especificação é feita por uma classe Java que acompanha cada especificação e age como intermediário entre a especificação e o sistema sob teste.

Para alguns exemplos simples e interessantes basta estudar o tutorial do Concordion.


Outro ponto interessante do Concordion é que você pode exercer diretamente código da camada da aplicação ou de negócio ou então usar uma API que navega páginas Web. O site do Concordion recomenda o uso do WebDriver.


Por enquanto é só. Espero que tenha ajudado a esclarecer a importância do BDD e do ATDD para uma melhor qualidade e arquitetura de software. Não fiquem acanhados de tirar dúvidas ou colocar comentários. Basta escrevê-las aqui!


5 Comentários:

At 7:40 PM, Blogger Juan disse...

Um exemplo mais concreto usando parametros, que creio que é o sweet spot, que permite que as frases possam ser reusadas em outros cenarios..

Dado que existe o cliente Juan
E o cliente Juan tem uma conta conta corrente numero 112323-2
E a conta 112323-2 tem saldo de 1500 reais
Quando o cheque numero 11221 de 1450 reais é compensado
Então a conta corrente numero 112323-2 fica com saldo de 50 reais

Para Ruby esta ficando muito legal a ideia de usar Cucumber (Story Runner) + Webrat que é parecido com Selenium porem sem usar o browser.

 
At 11:13 PM, Blogger André Faria disse...

Muito bom Papo, parabéns!

Assim como o Juan, também acho muito legal a idéia de se usar o cucumber.

 
At 1:14 AM, Blogger IgorCouto disse...

Muito bom o posto José Papo!

Agora juntando isso com o code coverage, fica sensacional.

Estou fazendo um teste dele com o ecclema.

[ ] 's

 
At 10:09 PM, Anonymous Guilherme Cirne disse...

Só uma pequena correção: o JBehave, a partir da versão 2, não é mais um framework BDD para testes unitários. É um framework BDD para testes de aceitação.

 
At 1:00 PM, Blogger Informática disse...

Olá José, primeiramente parabéns pelo artigo e pelas explicações sobre esta ferramenta.

José, estou estundando sobre ferramentas que fazem testes de aceitação. Atualmente estou estudando sobre um framework chamado "FITNESSE", que pelo que vi se parece muito com o "Concordion".

Mas, eu ainda não tenho experiência suficiente para saber qual das duas ferramentas é melhor para este propósito.

Pelo que li, até então, sobre o "Concordion" a vantagem dele em relação ao FITNESSE é que no framework concordion o teste pode ser escrito na forma de texto livre pelo cliente, já o fitnesse exige que os testes sejam escritos no formato de wiki e de forma tabular dificultando que eles sejam escritos pelo cliente.

Além do Concordion ser mais simples de instalar e usar. Como eu não conheço, bem as ferramentas, resolvi pedir sua ajuda.

Você poderia me informar quais as principais diferenças entre as duas
ferramentas? Ou qual a mais recomendável para testes de aceitação?

É mais vantagem usar o Concordion ou o FitNesse?

 

Postar um comentário

Links para este artigo:

Criar um link

<< Home


Veja as Estatísticas