ABAP Unit – Calculadora

Há um tempo, atrás eu escrevi que tinhamos que aprender muito com a cultura do comunidade Ruby on Rails. Nas comunidades Rails e Ruby programar orientado a tests unitários (TDD) faz parte da cultura. De acordo com essa filosofia, TODA lógica DEVE estar coberta por casos de testes. Se não há caso de teste, então não há necessidade de programar aquela funcionalidade.

Pode até parecer radical demais, mas podemos aprender muito com essas técnicas. Em ABAP temos o chamado ABAP Unit, onde a SAP provê uma ferramenta muito simples e poderosa para execução dos testes unitários.

Nesse artigo vou mostrar como usar o ABAP Unit em uma classe para gerenciar uma uma calculadora simples de quatro operações.

Classe ZCL_CALCULATOR

Atributos do ZCL_CALCULATOR

Métodos da classe ZCL_CALCULATOR.

A sequência das ações será a seguinte:

  1. Chama método ENTER_DIGIT( ) para cada dígito do primeiro número;
  2. Chama método ENTER_OPERATION( ). Nesse método o valor atual do DISPLAY é armazenado no atributo PREVIOUS_VALUE.
  3. Chama método ENTER_DIGIT( ) para cada dígito do segundo número;
  4. Chama método EXECUTE( ) que executa a operação entre o PREVIUS_VALUE e o DISPLAY. O resultado será armazenado no atributo DISPLAY e daí precisamos chamar o método GET_DISPLAY( ) para mostrar o valor do display.

Algumas validações de operação inválida e divisão por zero também estão implementadas, mesmo assim ainda faltam alguns controles básicos, que deixo para vocês implementarem e nos enviar o NUGG  corrigido.

Criando e Usando a Classe de Teste

Com os atributos e métodos criados, podemos criar a classe de teste unitário, usando o caminho indicado na figura abaixo:

Criando Classes de Teste

Para executar os tests unitários, usamos o seguinte item do menu:

Executando Testes Unitários

Para acessar a classe local de teste você usa o seguinte item do menu:

Acessando classe de teste unitário

Escrevendo Testes Unitários

Na classe unitária é onde programamos os testes que queremos que sistema execute quando rodarmos o teste unitário. Nesse artigo vamos estudar o método EXECUTE( ).

Dentro do método podemos testar quantos cenários quisermos. No caso estamos testando as quatro operações e mais uma divisão por zero. No teste unitário simulamos o uso da classe ZCL_CALCULATOR. No primeiro cenário testamos a soma dos números 25 e 16 onde o resultado esperado é 41. Entramos com os digitos 2 e 5, a operação de soma e daí os dígitos 1 e 6 e executamos o método EXECUTE( ). A mágica acontece no método CL_AUNIT_ASSERT=>ASSERT_EQUALS( ), onde passamos como parâmetros o valor esperado, o valor do resultado da execução do método EXECUTE( ) e a mensagem de erro. Se o valor esperado não for igual ao valor calculado um erro é contabilizado. Ao executarmos os testes unitários, temos um relatório de erro:

Unit Test report

Na figura acima temos a indicação de falha em um de nossos testes. Do lado direito do relatório de teste unitário, pode encontrar o detalhamento do erro:

Unit Test report

Repare na mensagem do erro: ‘Error 25 + 16 Expected: 41.00 actual: 42.00’. Esse mensagem foi gerado por esse teste (de um clique no link do Stack):

ABAP Unit - Cenário de soma

Por isso é interessante gerar uma mensagem bem explicativa.

Corrigindo o Erro

Sabemos que o erro foi no método EXECUTE( ), quando estamos fazendo uma soma. Isso significa que código está “quebrado” e devemos verificar o que há de errado com ele. Vejamos o que está acontecendo com o método em questão:

O erro está na soma, onde o resultado está sendo adicionado de um. Após a correção do código podemos executar o teste uniário novamente e veja o resultado:

Resultado ABAP Unit

Conclusão

Esse artigo tem como objetivo de apenas apresentar o ABAP Unit. Você consegue encontrar muito material sobre isso na internet,  mas o principal é a mudança de mentalidade. Quando entregamos uma classe com uma boa cobertura de uma suite de teste completa, fica muito fácil de identificar quando “quebramos” o código em uma alteração ou até mesmo se estamos programando e prevendo todas as situações para evitarmos short dumps em produção.

Com o tempo, podemos escrever primeiro a classe de teste e depois codificarmos a classe em si. Isso é o que chamamos de TDD.

Arquivos

Nesse arquivo NUGG você encontra a classe ZCL_CALCULATOR. Claro que é um exemplo bem simples e melhorias são muito bem vindas!

You may also like...