Orientações técnicas/Conceitos Gerais Testes Unitarios 1.1 (Edição mínima)

2013-01-09T20:01:03Z

Linha 1

<<TableOfContents>>

Linha 2

Linha 3

**Conceitos Gerais de Testes Unitários**

Linha 4

Linha 5

**1. Testes Unitários**

Linha 6

Linha 7

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.

Linha 8

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.

Linha 9

Linha 10

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.

Linha 11

Linha 12

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.

Linha 13

Linha 14

**2. TDD (test-driven development)**

Linha 15

Linha 16

É uma metodologia de desenvolvimento onde:

Linha 17

Linha 18

**a.** Esses testes são focalizados principalmente em testes unitários;

Linha 19

**b.** Você mantém um exaustivo conjunto de testes de programação;

Linha 20

**c.** Normalmente os testes são escritos pelo desenvolvedor que fez o código;

Linha 21

**d.** Irão assegurar o comportamento adequado do código;

Linha 22

**e.** Nenhum código vai para produção sem ter pelo menos um teste associado a ele;

Linha 23

**f.** Assegura que tudo foi testado antes de ser entregue;

Linha 24

**g.** Facilita o rastreamento de erro caso uma mudança ocasione um problema;

Linha 25

**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;

Linha 26

**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;

Linha 27

**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;

Linha 28

**k.** Os testes determinam como o código será escrito;

Linha 29

**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;

Linha 30

**m.** Implementação de maneira simples;

Linha 31

**n.** Facilita refatoração.

Linha 32

Linha 33

Linha 34

**2.1 Problemas na abordagem tradicional**

Linha 35

Linha 36

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

Linha 37

Linha 38

**a.** Caso os testes não sejam abrangentes, erros podem acontecer quando o sistema estiver em produção, causando problemas devastadores;

Linha 39

**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;

Linha 40

**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;

Linha 41

**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;

Linha 42

**e.** Caso os testes não sejam automatizados, eles não serão executados com frequência ou de forma diferente cada vez;

Linha 43

**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;

Linha 44

Linha 45

Linha 46

**2.2 Benefícios na utilização do TDD**

Linha 47

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

Linha 48

Linha 49

**a.** Resulta em código simples, claro e robusto;

Linha 50

**b.** Código fácil de estruturar, escrever, ler, entender, estender e manter;

Linha 51

**c.** Rastrear exatamente onde o problema ocorreu;

Linha 52

**d.** Os testes confirmam que as mudanças realizadas não afetaram o comportamento esperado;

Linha 53

**e.** Testes automatizados e realizados sempre da mesma forma;

Linha 54

**f.** Testes realizados pelo desenvolvedor que escreveu o código. Isso facilita a correção e não apresenta grandes perdas de tempo;

Linha 55

Linha 56

Linha 57

**3. Testes no framewok demoiselle**

Linha 58

Linha 59

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.

Linha 60

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.

Linha 61

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.

Linha 62

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.

Linha 1

~~New~~