Testes unitários com JUnit

O ser humano é suscetível a erros. Quando programamos, procuramos sempre desenvolver uma lógica que implemente o que é requisitado por alguém ou que está especificado em algum documento. Muitas vezes, sem perceber, cometemos pequenos deslizes ao programar, mas continuamos acreditando que nosso código está coerente e consistente. Para verificar, rodamos a nossa aplicação e observamos seu comportamento e suas respostas aos nossos cliques e dados que digitamos. Não ocorreu nenhum erro? Então está perfeito. Será mesmo? E se testarmos com outros dados? Ao inserirmos dados inválidos propositalmente, qual seria o resultado? O que aconteceria se um laço while fosse executado mais vezes do que o esperado? No caso de nosso método possuir um if/else, nosso dado de teste fez o if ser executado? O else foi testado em algum momento?

Olhamos de novo, mais 10 vezes, e não conseguimos ver erro nenhum. Estamos certos de que o código está correto. Pelo menos, pressupomos que esteja. Para ampliarmos nossa certeza, vamos conhecer um pouco sobre Testes de Software e aprender algumas técnicas que nos mostram que, apenas com concentração e boa intenção, não conseguimos enxergar os problemas que estão presentes.

O que é Teste de Software?

Durante o processo de desenvolvimento, há os momentos de verificar se o software que estamos construindo está correto e se o que estamos desenvolvendo é o que o cliente ou o usuário realmente quer. Estes momentos de verificação fazem parte de um processo chamado Verificação e Validação, também referenciado como V & V, e devem ocorrer em várias fases da construção do software. Validação é o processo que visa garantir que se está construindo o programa que o cliente de fato deseja utilizar, com as funcionalidades que ele espera que estejam disponíveis. Ou seja, conseguimos compreender o que o cliente quer e o entregamos conforme acertado. Verificação é o processo de garantir que o produto de software está sendo bem construído, executando corretamente, mostrando as mensagens corretas, sem ocorrer falhas durante sua operação. Assim esperamos.

Teste de Software é parte integrante de V & V e corresponde ao processo que consiste de todas as atividades do ciclo de vida referentes à avaliação do software, com o objetivo de se determinar três coisas:

1. que o mesmo satisfaz aos requisitos especificados;
2. que o mesmo está apto para ser liberado para o cliente;
3. para encontrar defeitos, motivo que todos pensam ser o único. Portanto, testar um programa não é apenas procurar erros, é um processo bem mais amplo, com seus papéis, atividades e artefatos resultantes.

Um Caso de Teste, que nós chamamos apenas de Teste, consiste de:

• Um conjunto de valores de entrada para o sistema;
• As ações a serem executadas pelo testador ou outro programa que interaja com o software que está sendo testado;
• Os resultados esperados como consequências das ações executadas; e
• As pós-condições, que são o resultado final gerado como consequência do que foi executado ao longo do teste.

Para conhecer os vários tipos de teste e entender em que momento eles se aplicam, veja a Figura 1, conhecida como Modelo V, que mostra como as atividades de teste podem ser integradas em cada fase do ciclo de vida de desenvolvimento. Quatro tipos diferentes são mostrados, onde cada um deles é aplicado em um nível diferente dos artefatos da aplicação, desde um simples método até o sistema inteiro. Por isso eles definem os Níveis de Teste.

Níveis de Teste – entendendo melhor

Vamos entender estes “níveis” melhor. Após a codificação do sistema, criação das classes, definição de seus atributos e implementação de seus métodos, iniciamos o desenvolvimento dos Testes Unitários, que consiste em checar se os métodos de uma classe funcionam corretamente (este é o foco deste artigo).

Depois que todos os métodos que interessam foram testados separadamente, inicia-se os Testes de Integração, onde se procura verificar a comunicação entre as classes. Por exemplo, procura-se verificar os resultados dos métodos de uma determinada classe quando chamados por métodos de outras. Nesta fase, vai-se integrando do nível mais granulado, de classe em classe, indo até componentes inteiros interagindo com outros, mas sempre observando as estruturas internas que estão sendo testadas nos códigos, suas condições e seus laços. Estes testes, os unitários e os de integração, são também chamados de “Testes de Caixa Branca”, porque estamos olhando o que há dentro do código-fonte para poder testá-los.

Após a integração, se junta todos os componentes e demais recursos que compõem o sistema e começam-se os Testes de Sistema. Neste nível não se checa mais o código, mas se a aplicação está fazendo corretamente o que está especificado nos requisitos, testando-a através das interfaces gráficas, checando relatórios e demais artefatos gerados, simulando mais ou menos o que um usuário faria ao usar o sistema.

Por último, os Testes de Aceitação são realizados, geralmente, pelos próprios clientes ou usuários, onde se procura verificar se as necessidades deles foram adequadamente atendidas e se o sistema oferece o que eles esperam. Se estiver OK, o sistema é aceito e vai para produção. Tanto os testes de sistema quanto os de aceitação, diferentemente dos dois primeiros, são chamados de “Testes de Caixa Preta”, pois não se sabe como o código está estruturado, não se tem a visão de dentro da caixa. Testa-se sem se preocupar com isso, pois o que interessa agora é a funcionalidade de alto nível, na visão do usuário ou cliente.