Testando Cartão de História

Oi pessoal,

Este post vem para fechar a serie de publicações referentes a teste de software. Para este fechamento vamos falar de Desenvolvimento de Software Orientado ao Comportamento. O comportamento vem da definição dos testes necessários para a implementação do Cartão de Historia e como o software deve se comportar a nível de execução após o teste estar implementado.

Esta imagem já faz parte do Blog, mas ela vai servir como material complementar.



Link do post original da mensagem: http://blogdoabu.blogspot.com/2008/04/bdd-e-scrum.html

Uma das grandes razões para se escrever testes é para refinarmos o entendimento dos requisitos. No trabalho de analise de sistema a equipe de desenvolvimento e o cliente realiza uma conversação, onde neste bate papo podemos identificar detalhes complementares dos requisitos analisados.

Um cartão de história é uma técnica de se escrever um requisito e este requisito deve possuir um conjunto de dados para podermos ter a informação que ele armazena. Entre estes dados podemos citar um código único, um título, descrição do cartão e anotações das conversas entre o cliente e a equipe de desenvolvimento.

As anotações referentes aos itens a serem testados, geralmente são escritas nas costas dos cartões. Podemos ver maiores detalhes sobre cartões de histórias nos links:

http://blogdoabu.blogspot.com/2008/04/exemplo-de-carto-de-historia.html

http://blogdoabu.blogspot.com/2008/04/cares-de-historia.html

Os testes servem para completar os detalhes existentes nos requisitos identificados, detalhes que passam despercebidas no processo de análise de sistema. Eu costumo fazer uma comparação entre o analista de testes e o analista de sistemas onde o primeiro se preocupado com os caminhos alternativos e exceções, enquanto o segundo esta focado no fluxo da informação do sistema.

Podemos dizer que os objetivos dos testes não são apenas para testar o software e sim permitir também uma identificação de funcionalidades do requisito.

Podemos utilizar os testes como uma ferramenta de apoio a gestão da implementação do requisito, estes testes servem para demonstrar se o requisito foi implementado por inteiro, pois a totalidade da implementação do cartão história é definida pela implementação das funcionalidades que devem ser testadas.

Um exemplo de cartão de história para ser testado é:

Como um cliente desejo pagar uma compra on-line com cartão de crédito, de modo que eu passa finalizar a minha compra com o pagamento eletrônico.

Os testes para este Cartão História podem ser:

- Testar pagamento com cartão Visa, Máster Card e Americam Express e ter o resultado de ok(pass);
- Testar pagamento com cartão Diner´s Club e ter resultado de falha (fail);
- Testar pagamento com números bons e ruins de cartão de crédito;
- Testar pagamento com cartões com data expirada (vencida);
- Testar pagamento com cartão que o limite de compra não comporta o pagamento desejado (Limite excedido).

Mas Como o teste pode direcionar o desenvolvimento? Vamos pegar o primeiro teste:

Pagamento com cartões Visa, Master Card e Americam Express.

O primeiro passo é criar uma classe de testes e dentro desta classe criar um método para representar o teste a ser executado.

O próximo passo é implementar o método coma chamativa da classe de negócio a ser testada e que ainda não existe.

Esta implementação gera um erro, pois faz referência a uma classe que ainda não existe. Para resolvermos este problema, criamos uma classe de negócio que vai ser testada e após esta classe ser criada, nosso código não possui mais erro de referência.

Devemos continuar a implementação do método que representa o teste. Colocaremos neste método os códigos necessários para passamos a informação “tipo de cartão de crédito” a classe de negócio. Novamente teremos um erro, pois a classe de negócio não está preparada para esta informação. Com essa situação de erro devemos implementar na classe de negócio o recebimento da informação “tipo de cartão de crédito”.

Devemos lembrar que o método que está executando o teste espera ter a sua execução bem sucedida para os tipos de cartão de crédito: Visa, Master Card e Americam Express.

A nossa classe de negócio até o momento está apenas recebendo o tipo de cartão, mas não retornas nenhuma informação se o cartão é válido ou não. Então devemos na classe de negócio implementar um método que retorna se o tipo de cartão de crédito é um cartão válido ou não.

O nosso teste passa a ter o seguinte comportamento:

If Venda(Visa) then pass

If Venda( Master Card ) then pass

If Venda(Americam Express) then pass

If Venda(Diner´s Club) then fail

Podemos melhorar o código criando um método que determine o tipo de cartão de credito. Com este método a nossa implementação da classe de negócio fica com a forma:

Classe:Venda

método: defineTipoCartao(tipo)

parâmetro :tipo do campo

retorno: verdadeiro para cartão válido e Falso para cartão não válido

O teste implementado conduz a implementação e comportamento do software. Com este teste podemos observar uma falta de definição caso o cartão não seja válido, isto é, como o processo de venda vai executar o fluxo de erro. Fica em aberto as definições do comportamento para: cancelando a venda, comunicando ao cliente que seu cartão não é válido e qual a mensagem de erro a ser apresentado ao usuário.

O método tipoCartaoCredito pode ser projeto para retornar True/false ou uma exceção. No caso de uma exceção podemos colocar dentro dela a mensagem de erro.

Usando esta técnica nós vamos descobrindo a melhor forma de desenvolver o sistema no processo de desenvolvimento e para cada funcionalidade implementada, existe uma cobertura de teste para esta funcionalidade.

O termo desenvolvimento direcionado a comportamento vem destas características apresentadas neste post, onde o nosso código será construído conforme o comportamento que esperamos do tratamento dos testes, isto é, o descobrimento desse comportamento vêm dos testes idealizados.

Referencias bibliográficas:
User Stories Applied: For Agile Software Development (Addison-Wesley Signature Series)
by Mike Cohn (Author)