Orientações técnicas/Conceitos Gerais Testes Unitarios

Conceitos Gerais de Testes Unitários

1. Testes Unitários

São testes que verificam se uma parte específica do código, costumeiramente a nível de função, está funcionando corretamente. Em um ambiente orientado a objetos é usualmente a nível de classes e a mínima unidade de testes inclui construtores e destrutores. O objetivo do teste unitário é assegurar que cada unidade está funcionando de acordo com sua especificação funcional. Estes tipos de testes são frequentemente escritos por desenvolvedores quando trabalham no código, para assegurar que a função específica está executando como esperado. Uma função deve ter muitos testes para dar cobertura a todos os caminhos possíveis do seu código. Sozinho, o teste unitário não pode verificar a funcionalidade de uma parte do software, mas em contrapartida é usado para assegurar que os blocos constituintes do software trabalham independentes dos demais.

Todo o teste unitário necessita de um planejamento prévio. Deve ser de entendimento do desenvolvedor os requisitos que aquela funcionalidade tem que cobrir, qual a sua entrada e qual a sua saída e como se processa o fluxo interno dos dados. Então casos de testes deverão ser formulados para garantir que todos os pontos do fluxo serão verificados pelo menos uma vez pelos testes. Nesse caso são aplicadas as técnicas que vimos anteriormente para a realização dos testes, como o particionamento de equivalência e a análise de valor limite, para a elaboração dos casos de testes.

Uma vez elaborados os casos de testes, escreve-se a classe de teste (driver) com um método para cada caso de teste levantado. Caso seja necessário executar comportamentos ainda não implementados, utiliza-se da criação de “stubs” (outra abordagem utilizada é a criação de objetos Mock) que substituirão temporariamente o comportamento esperado. Realiza-se o teste na sua forma mais simples e a partir da classe de teste sendo executada com sucesso, faz-se um refatoramento (que será explicado posteriormente) para remover duplicidades e deixar a classe de teste o mais simples e estruturada possível.

2. TDD (test-driven development)

É uma metodologia de desenvolvimento onde:

a. Esses testes são focalizados principalmente em testes unitários; b. Você mantém um exaustivo conjunto de testes de programação; c. Normalmente os testes são escritos pelo desenvolvedor que fez o código; d. Irão assegurar o comportamento adequado do código; e. Nenhum código vai para produção sem ter pelo menos um teste associado a ele; f. Assegura que tudo foi testado antes de ser entregue; g. Facilita o rastreamento de erro caso uma mudança ocasione um problema; h. Os testes são escritos em pequenas partes seguidos por pequenas partes de código, ou seja, os testes direcionam como o código deverá ser estruturado; i. Utilização do próprio compilador para descobrir erros. Normalmente as interfaces de desenvolvimento contam com mecanismos que realizam um “trace” no código a procura de erros. Também são utilizados para a criação das classes referenciadas nos códigos de teste, agilizando a codificação; j. Necessário escrever o código para ter sucesso no teste. Sempre a sequência de desenvolvimento orientado a testes será escrever primeiramente as classes de testes e depois o código propriamente dito que deverá obrigatoriamente satisfazer por completo os testes que foram definidos; k. Os testes determinam como o código será escrito; l. Você só implementa o mínimo que deve ser implementado, sem código em excesso. Depois disso utiliza-se técnicas de refatoramento para melhorar o seu código inicial; m. Implementação de maneira simples; n. Facilita refatoração.

2.1 Problemas na abordagem tradicional

Alguns problemas em relação aos testes realizados utilizando a abordagem tradicional podem ser elencados, como:

a. Caso os testes não sejam abrangentes, erros podem acontecer quando o sistema estiver em produção, causando problemas devastadores; b. Testes são frequentemente realizados quando todo o código foi escrito, ou quando o desenvolvedor não está mais envolvido com a tarefa. Isso consome muito tempo para retornar ao entendimento do código para lidar com os problemas; c. Frequentemente os testes são escritos por outras pessoas que não trabalharam no código. Dessa forma essas pessoas podem não entender todos os detalhes do código bem como não realizar testes importantes; d. Caso os testes sejam baseados em documentação que não seja o próprio código, uma documentação desatualizada poderá causar problema durante os testes; e. Caso os testes não sejam automatizados, eles não serão executados com frequência ou de forma diferente cada vez; f. Correções podem causar efeitos colaterais em outros lugares que não foram previstos. A infraestrutura de testes existentes poderá não ser capaz de encontrar esses problemas;

2.2 Benefícios na utilização do TDD Alguns benefícios na utilização do TDD como metodologia podem ser elencados, como:

a. Resulta em código simples, claro e robusto; b. Código fácil de estruturar, escrever, ler, entender, estender e manter; c. Rastrear exatamente onde o problema ocorreu; d. Os testes confirmam que as mudanças realizadas não afetaram o comportamento esperado; e. Testes automatizados e realizados sempre da mesma forma; f. Testes realizados pelo desenvolvedor que escreveu o código. Isso facilita a correção e não apresenta grandes perdas de tempo;

3. Testes no framewok demoiselle

Os testes realizados no framework demoiselle e em suas aplicações (ex. demoiselle-crud) utilizam atualmente três frameworks de testes: JUnit, Easymock e JMockit. Esses framewoks serão rapidamente abordados nos outros tópicos desse wiki na forma de uma descrição do framework, de como e quando se deve utilizá-los durante o desenvolvimento das aplicações. Temos como intuito direcionar o melhor framework a ser utilizado em determinada ocasião, ou mesmo a utilização em conjunto de mais de um framework de testes para um determinado teste unitário de classe. O intuito não é aprofundar nas classe de cada framework de teste. Isso poderá ser feito diretamente na documentação de cada projeto, bem como em artigos bastante abundantes na internet para cada framework aqui utilizado.