Orientações técnicas/Práticas de Testes

Orientações técnicas/Práticas de Testes 1.1 (Edição mínima)

2013-01-09T20:00:37Z

Linha 1

<<TableOfContents>>

Linha 2

Linha 3

**Práticas de Testes**

Linha 4

Linha 5

1. Objetivo

Linha 6

}

Linha 7

Linha 8

2. Testes Unitários

Linha 9

3. JUnit

Linha 10

4. Easymock

Linha 11

5. JMockit

Linha 1

~~New~~

Orientações técnicas/Práticas de Testes 1.2 (Edição mínima)

2013-01-09T20:00:37Z

Orientações técnicas/Práticas de Testes 1.3 (Edição mínima)

2013-01-09T20:00:37Z

Linha 9

2. 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.

Orientações técnicas/Práticas de Testes 1.4 (Edição mínima)

2013-01-09T20:00:37Z

Linha 13

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.1 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.2 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.3 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;

Orientações técnicas/Práticas de Testes 1.5 (Edição mínima)

2013-01-09T20:00:38Z

Linha 5

1. Objetivo

**1. Objetivo**

Linha 7

}

2. Testes Unitários**

Linha 8

~~2. Testes Unitários~~

Linha 16

2.1 TDD (test-driven development)**

Linha 17

~~2.1 TDD (test-driven development)~~

Linha 21

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

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

Linha 22

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

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

Linha 23

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

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

Linha 24

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

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

Linha 25

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

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

Linha 26

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

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

Linha 27

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

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

Linha 28

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;

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

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

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

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

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

Linha 32

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;

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

m. Implementação de maneira simples;

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

Linha 34

n. Facilita refatoração.

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

Linha 36

2.2 Problemas na abordagem tradicional**

Linha 37

~~2.2 Problemas na abordagem tradicional~~

Linha 41

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

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

Linha 42

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

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

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;

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

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

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

Linha 46

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;

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

2.3 Benefícios na utilização do TDD

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

Linha 52

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

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

Linha 53

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

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

Linha 54

c. Rastrear exatamente onde o problema ocorreu;

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

Linha 55

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

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

Linha 56

e. Testes automatizados e realizados sempre da mesma forma;

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

Linha 57

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

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

Linha 61

3. JUnit

**3. JUnit**

Linha 62

4. Easymock

**4. Easymock**

Linha 63

5. JMockit

**5. JMockit**

Orientações técnicas/Práticas de Testes 1.6 (Edição mínima)

2013-01-09T20:00:38Z

Linha 6

**1. Objetivo**

Linha 7

2. Testes Unitários**

Linha 9

**2. Testes Unitários**

Linha 16

2.1 TDD (test-driven development)**

Linha 19

**2.1 TDD (test-driven development)**

Linha 38

Linha 39

**2.2 Problemas na abordagem tradicional**

Linha 36

Linha 37

2.2 Problemas na abordagem tradicional**

Orientações técnicas/Práticas de Testes 1.7 (Edição mínima)

2013-01-09T20:00:38Z

Linha 64

**3. JUnit**

<P> Para entendermos o JUnit precisamos entender dois conceitos fundamentais utilizados em Testes de Caixa Branca. São eles os conceitos de: Driver e Stub.</P>

Driver é um módulo de software utilizado para executar um determinado módulo de teste em um código específico a ser testado. Frequentemente provê os dados de entrada para os testes, controles utilizados para a realização dos testes, monitora a execução dos testes e fornece relatórios de saída com os resultados dos testes realizados.

Stub é módulo que simula um componente que ainda não foi desenvolvido e necessita ser utilizado no teste, formalmente definido como uma declaração substituta de parte do programa que será definida em outra ocasião.

Em outras palavras, o driver é o veículo utilizado para se realizar os testes e o stub serve de atalho para que os testes não precisem esperar uma determinada implementação para que possam ser realizados.

O JUnit é um framework opensource [[http://www.junit.org|http://www.junit.org JUnit]], criado por Eric Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java. Ele será utilizado como driver para os testes unitários a serem realizados no software sob testes. Esse framework facilita a criação de código para a automação de testes unitários com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão.

Orientações técnicas/Práticas de Testes 1.8 (Edição mínima)

2013-01-09T20:00:38Z

Linha 62

**3. Testes no framewok demoiselle**

Linha 64

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 65

Esses framewoks serão rapidamente abordados abaixo na forma de como e quando se deve utilizá-los durante o desenvolvimento das aplicações.

Linha 66

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 67

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 63

~~**3. JUnit**~~

Linha 69

**4. JUnit**

Linha 69

Linha 75

O JUnit é um framework opensource [[http://www.junit.org|http://www.junit.org ~~JUnit~~]], criado por Eric Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java. Ele será utilizado como driver para os testes unitários a serem realizados no software sob testes. Esse framework facilita a criação de código para a automação de testes unitários com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão.

O JUnit é um framework opensource [[http://www.junit.org|http://www.junit.org]], criado por Eric Gamma e Kent Beck, com suporte à criação de testes automatizados na linguagem de programação Java. Ele será utilizado como driver para os testes unitários a serem realizados no software sob testes. Esse framework facilita a criação de código para a automação de testes unitários com apresentação dos resultados. Com ele, pode ser verificado se cada método de uma classe funciona da forma esperada, exibindo possíveis erros ou falhas podendo ser utilizado tanto para a execução de baterias de testes como para extensão.

Linha 77

**4.1 Instalação**

Para se instalar o JUnit deve-se baixar o seu .jar da página do projeto [[http://www.junit.org|http://www.junit.org]] e incluir no classpath de seu projeto. No caso de projetos que utilizam o Maven, como é o caso dos projetos demoiselle, deverá ser colocada a seguinte dependência no arquivo pom.xml:

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

Linha 86

Linha 87

**4.2 Utilização**

Linha 88

Para utilização do JUnit integrado ao Eclipse IDE podemos tomar como base o seguinte artigo: [[http://onjava.com/pub/a/onjava/2004/02/04/juie.html]]. Além da documentação disponível no próprio site do projeto JUnit.

Linha 89

No caso dos projetos utilizando o framework demoiselle, em particular o demoiselle-crud, o JUnit já é disponibilizado juntamente com o framework, o que dispensa sua instalação prévia.

Linha 90

Vale como recomendação de boa prática que seja criado um projeto de testes anexo ao projeto em desenvolvimento. Nesse projeto de testes serão incluídos os casos de teste para cada classe desenvolvida no projeto principal.

Linha 91

É interessante que dentro do projeto de testes a estrutura de pacotes do projeto principal seja mantida, para facilitar a navegação pelo desenvolvedor.

Linha 92

Outra orientação de boa prática é que o nome das classes de teste sejam o mesmo nome das classes a serem testadas, exceto a terminação do nome com a inclusão da palavra Test. Exemplo: classe a ser testada ClasseGenerica.java, classe de testes ClasseGenericaTest.java.

Linha 93

Dentro de cada classe de testes é interessante que o nome de cada caso de teste que representará um teste específico para um método da classe principal, seja um nome de faça referência ao nome do método a ser testado e o tipo de teste que está sendo realizado.

Linha 94

Exemplo:

Linha 95

método principal a ser testado: public void insert()

Linha 96

}

Linha 97

Linha 98

No exemplo acima temos dois casos de testes para o mesmo método insert() da classe principal a ser testada. Fica claro que método está sendo testado e o tipo de teste que está sendo realizado. Outra orientação é a inclusão de comentários no cabeçalho de cada método de testes explicando como o teste será realizado.

Linha 99

Linha 100

Linha 72

Linha 101

**4. Easymock**

**5. Easymock**

Linha 73

Linha 102

**5. JMockit**

**6. JMockit**

Linha 103

**7. Quando usar cada framework durante o desenvolvimento dos testes?**

Orientações técnicas/Práticas de Testes 1.9 (Edição mínima)

2013-01-09T20:00:38Z

Linha 88

Para utilização do JUnit integrado ao Eclipse IDE podemos tomar como base o seguinte artigo: ['Como utilizar JUnit com Eclipse' http://onjava.com/pub/a/onjava/2004/02/04/juie.html]. Além da documentação disponível no próprio site do projeto JUnit.

Orientações técnicas/Práticas de Testes 2.0 (Edição mínima)

2013-01-09T20:00:38Z

Linha 65

Esses framewoks serão rapidamente abordados abaixo na forma de como e quando se deve utilizá-los durante o desenvolvimento das aplicações.

Esses framewoks serão rapidamente abordados abaixo na forma de uma descrição do framework, de como e quando se deve utilizá-los durante o desenvolvimento das aplicações.

Linha 88

Para utilização do JUnit integrado ao Eclipse IDE podemos tomar como base o seguinte artigo: [~~'Como utilizar JUnit com Eclipse'~~ http://onjava.com/pub/a/onjava/2004/02/04/juie.html]. Além da documentação disponível no próprio site do projeto JUnit.

Para utilização do JUnit integrado ao Eclipse IDE podemos tomar como base o seguinte artigo: [[http://onjava.com/pub/a/onjava/2004/02/04/juie.html|'Como utilizar JUnit com Eclipse']]. Além da documentação disponível no próprio site do projeto JUnit.

Linha 103

**7. Quando usar cada framework durante o desenvolvimento dos testes?**

**7. Quando usar cada framework de testes durante o desenvolvimento dos testes unitários ?**

Orientações técnicas/Práticas de Testes 2.1 (Edição mínima)

2013-01-09T20:00:38Z

Linha 87

**5. Easymock**

Linha 88

O Easymock é uma biblioteca utilizada para para "mockar" objetos e interfaces dinamicamente.

Linha 89

É dividido em dois pacotes. O primeiro pacote é o Easymock, responsável para criar objetos mock referente a interfaces. O segundo é o Easymock Classextension, responsável por criar objetos mock para classes.

Linha 90

O Easymock poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor.

Linha 91

Linha 87

Linha 92

**4.2 Utilização**

**5.1 Instalação**

Linha 93

Poderá ser adicionado ao projeto pelo Maven, incluindo as seguintes dependências no pom.xml:

Linha 94

Linha 95

<groupId>org.easymock</groupId>

Linha 96

<artifactId>easymock</artifactId>

Linha 97

Linha 98

Linha 99

</dependency>

Linha 100

Linha 101

<groupId>easymock</groupId>

Linha 102

<artifactId>easymockclassextension</artifactId>

Linha 103

Linha 104

Linha 105

</dependency>

Linha 106

Linha 107

Para a instalação manual, deverá proceder o download da versão através dos links disponibilizados na página do projeto [[http://www.easymock.org|http://www.easymock.org]].Após descompactar, o arquivo easymock.jar deverá ser adicionado ao classpath do seu projeto.

Linha 108

Linha 109

Linha 110

**6. JMockit**

Linha 111

**7. Quando usar cada framework de testes durante o desenvolvimento dos testes unitários ?**

Linha 112

Linha 113

JUnit

Linha 125

O JUnit será utilizado para todos os casos de testes do projeto, inclusive os que utilizam o Easymock, Easymock classextendion e o JMockit, ou a combinação deles.

Linha 127

Easymock

No caso das bibliotecas do Easymock existirá um emprego específico do Easymock ou do Easymock Classextension dependendo do foco do teste.

Para o caso de haver a necessidade de se mockar uma interface, deverá ser utilizado o Easymock. Já para os casos de haver a necessidade de mockar classes, o classextension será o indicado.

A utilização do Easymock em um modo geral será nos casos em que são passadas classes ou interfaces como parâmetros dentro da chamada de métodos das classes sob testes. No caso de serem necessários mocks para classes internas ao método que está sendo testado, o indicado é se utilizar o JMockit para substituir a execução dessa classe.

Outro indicador de se utilizar o Easymock é a necessidade de serem mockados somente alguns métodos e seus retornos da classe em questão. O que não acontece com o JMockit quando se trata de interfaces, onde ele força a implementação (ou pelo menos a declaração) de todos os métodos da interface.

A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado,

Linha 134

JMockit

Linha 135

Como já foi citado anteriormente, a utilização do JMockit se faz interessante quando houver a necessidade de se mockar uma classe que está sendo utilizada internamente ao método da classe sob testes. Ou seja, essa classe não está sendo passada como parâmetro para o método que está sendo testado, porém em um determinado momento de sua execução a chamará, o que por ventura poderá ocasionar um erro dependendo do contexto do teste. Nesses casos o JMockit é recomendado, pois poderemos alterar o comportamento dos métodos que são chamados de classes terceiras que não estão sendo alvo do teste, porém estão dentro do escopo do método da classe sob testes.

Linha 136

No caso de uso do JMockit não implica a não utilização do Easymock, pelo contrário, poderemos utilizar um mix das duas soluções em conjunto.

Linha 101

~~**5. Easymock**~~

Linha 102

~~**6. JMockit**~~

Linha 103

~~**7. Quando usar cada framework de testes durante o desenvolvimento dos testes unitários ?**~~

Orientações técnicas/Práticas de Testes 2.2 (Edição mínima)

2013-01-09T20:00:39Z

Linha 111

**6. JMockit**

O JMokit também é uma biblioteca utilizada para se escrever objetos mock para testes de classes java.

A diferenciação do Easymock, entre outras, se dá pelo fato da possibilidade de utilizando o JMockit modificar comportamentos de classes e métodos estáticos, finais e construtores. Sendo dessa forma mais robusto e abrangente que o Easymock.

O JMocki poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor, bem como em conjunto com a utilização do Easymock e do Easymock Classextension.

**6.1 Instalação**

Poderá ser adicionado ao projeto pelo Maven, incluindo as seguintes dependências no pom.xml:

<groupId>mockit</groupId>

<artifactId>jmockit</artifactId>

<version>${jmockit.version}</version>

</dependency>

Também deverão ser configurados os determinados plugins na sessão de build para garantir a correta cópia e utilização do .jar:

<artifactId>maven-dependency-plugin</artifactId>

<phase>generate-test-resources</phase>

<goals>

</goals>

<groupId>mockit</groupId>

<artifactId>jmockit</artifactId>

<version>${jmockit.version}</version>

<outputDirectory>${project.build.directory}</outputDirectory>

</artifactItem>

</artifactItems>

</configuration>

</execution>

</executions>

</plugin>

...

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-surefire-plugin</artifactId>

<argLine>-javaagent:${project.build.directory}/jmockit-${jmockit.version}.jar</argLine>

</configuration>

</plugin>

Para a instalação manual, deverá proceder o download da versão através dos links disponibilizados na página do projeto [[http://code.google.com/p/jmockit| http://code.google.com/p/jmockit]].Após descompactar, o arquivo jmockit.jar deverá ser adicionado ao classpath e no diretório de output do seu projeto.

Linha 169

**JUnit**

Linha 113

~~JUnit~~

Linha 127

Linha 183

Easymock

**Easymock**

Linha 132

Linha 188

A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado,

A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado.

Linha 189

Uma limitação para a utilização do Easymock é a impossibilidade de se mockar métodos privados, estáticos e finais das classes.

Linha 191

**JMockit**

Linha 134

~~JMockit~~

Orientações técnicas/Práticas de Testes 2.3 (Edição mínima)

2013-01-09T20:00:39Z

Linha 190

A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado.

Uma limitação para a utilização do Easymock é a impossibilidade de se mockar métodos privados, estáticos e finais das classes.

A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado.

Uma limitação para a utilização do Easymock é a impossibilidade de se mockar métodos privados, estáticos e finais das classes.

Segue abaixo um exemplo de utilização do Easymock nos testes das classes do demoiselle-crud.

A classe sob testes é a MessageDecorator e o método que se deseja testar especificamente dessa classe é o método getLocale()

Para essa caso foi criada uma classe CrudMessageDecoratorTest para a realização dos casos de testes. Veja classe abaixo.

Linha 194

}

private ICrudMessage crudMessage;

/**

* Initialize test class creating a mock object from ICrudMessage interface

@Before

public void setUp() throws Exception {

crudMessage = EasyMock.createMock(ICrudMessage.class);

EasyMock.expect(crudMessage.getLabel()).andReturn("myLabel").anyTimes();

String key = "crud.message.ok";

EasyMock.expect(crudMessage.getKey()).andReturn(key).anyTimes();

EasyMock.expect(crudMessage.getCustomPattern()).andReturn(key.replaceAll("crud.", "app.myMB.")).anyTimes();

Locale loc = new Locale("pt", "Br");

EasyMock.expect(crudMessage.getLocale()).andReturn(loc).anyTimes();

EasyMock.expect(crudMessage.getResourceName()).andReturn("META-INF/crud-messages").anyTimes();

EasyMock.expect(crudMessage.getAppResourceName()).andReturn("messages").anyTimes();

EasyMock.expect(crudMessage.getSeverity()).andReturn(Severity.ERROR).anyTimes();

EasyMock.replay(crudMessage);

}

@Test

public void testGetLocale() {

MessageDecorator msgDecorator = new MessageDecorator(crudMessage, "test");

Assert.assertEquals("pt_BR", msgDecorator.getLocale().toString());

}

Notem que no método setUp() da classe de testes foi criado um mock para a interface ICrudMessage utilizando o Easymock. Nele foram ensinados os comportamentos para diversos métodos dessa interface, bem como os retornos esperados. Já no caso de teste testGetLocale() foi passado no construtor do objeto da classe sob testes nosso objeto mock (MessageDecorator msgDecorator = new MessageDecorator(crudMessage, "test");)

Linha 234

Exemplo de utilização do JMockit juntamente com Easymock.

A classe sob testes é a ResourceBundleManager e os métodos em testes são getMessage() e getCurrentLoader().

No caso do teste para o getMessage(), internamente a esse método é feito um chamado para o método getCurrentInstance da classe FacesContext. Nesse caso é indicado mockar essa classe e o comportamento do método. Para isso foi utilizado JMokit. Já para se utilizar esse método foi necessário mockar o objeto de retorno do tipo FacesContext. Nesse caso foi utilizado o Easymock para resolver a questão. Veja código abaixo.

public class ResourceBundleManagerTest extends TestCase {

private ResourceBundleManager bm = null;

public static abstract class MockFacesContext

{

@Mock

}

FacesContext ctx = EasyMock.createMock(FacesContext.class);

Application app = EasyMock.createMock(Application.class);

ELContext ectx = EasyMock.createMock(ELContext.class);

ValueExpression vexp = EasyMock.createMock(ValueExpression.class);

EasyMock.expect(vexp.getValue(EasyMock.isA(ELContext.class))).andReturn("test");

EasyMock.replay(vexp);

EasyMock.replay(ectx);

ExpressionFactory exf = EasyMock.createMock(ExpressionFactory.class);

EasyMock.expect(exf.createValueExpression(EasyMock.isA(ELContext.class), EasyMock.isA(String.class),EasyMock.isA(Class.class))).andReturn(vexp);

EasyMock.replay(exf);

EasyMock.expect(app.getExpressionFactory()).andReturn(exf);

EasyMock.replay(app);

EasyMock.expect(ctx.getApplication()).andReturn(app);

EasyMock.expect(ctx.getELContext()).andReturn(ectx);

EasyMock.replay(ctx);

return ctx;

}

public void setUp(){

bm = new ResourceBundleManager();

}

public void testGetMessageFromResourceBundle(){

Mockit.setUpMock(FacesContext.class, MockFacesContext.class);

String msg = bm.getMessage("test");

assertEquals("test", msg);

}

public void testGetCurrentLoader(){

NoLayers nl = new NoLayers();

ClassLoader loader = bm.getCurrentLoader((Object)nl);

assertNotNull(loader);

}

Orientações técnicas/Práticas de Testes 2.4 (Edição mínima)

2013-01-09T20:00:39Z

Linha 229

}

Orientações técnicas/Práticas de Testes 2.5 (Edição mínima)

2013-01-09T20:00:39Z

Linha 114

O JMocki poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor, bem como em conjunto com a utilização do Easymock e do Easymock Classextension.

O JMockit poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor, bem como em conjunto com a utilização do Easymock e do Easymock Classextension.

Orientações técnicas/Práticas de Testes 2.6 (Edição mínima)

2013-01-09T20:00:39Z

Linha 123

<version>~~${jmockit~~.~~version}~~</version>

Linha 143

<version>~~${jmockit~~.~~version}~~</version>

Linha 161

<argLine>-javaagent:${project.build.directory}/jmockit-~~${jmockit~~.~~version}~~.jar</argLine>

<argLine>-javaagent:${project.build.directory}/jmockit-0.998.jar</argLine>

Orientações técnicas/Práticas de Testes 2.7 (Edição mínima)

2013-01-09T20:00:39Z

Linha 292

}

Orientações técnicas/Práticas de Testes 2.8 (Edição mínima)

2013-01-09T20:00:39Z

Linha 5

* [[Orientações técnicas/Conceitos Gerais Testes Unitarios | Conceitos Gerais de Testes Unitários]]

Linha 6

* [[Orientações técnicas/Melhores Praticas | Melhores Práticas]]

Linha 7

* [[Orientações técnicas/JUnit | JUnit]]

Linha 8

* [[Orientações técnicas/Easymock | Easymock]]

Linha 9

* [[Orientações técnicas/JMockit | JMockit]]

Linha 10

* [[Orientações técnicas/Quando Usar Framework Testes | Quando utilizar cada framework de Testes]]

Linha 5

~~**1. Objetivo**~~

Linha 6

Linha 7

}

Linha 8

Linha 9

Linha 10

~~**2. Testes Unitários**~~

Linha 11

Linha 12

Linha 13

Linha 14

Linha 15

Linha 16

Linha 17

Linha 18

Linha 19

~~**2.1 TDD (test-driven development)**~~

Linha 20

Linha 21

~~É uma metodologia de desenvolvimento onde:~~

Linha 22

Linha 23

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

Linha 24

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

Linha 25

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

Linha 26

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

Linha 27

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

Linha 28

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

Linha 29

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

Linha 30

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

Linha 32

Linha 33

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

Linha 34

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

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

Linha 36

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

Linha 37

Linha 38

Linha 39

~~**2.2 Problemas na abordagem tradicional**~~

Linha 40

Linha 41

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

Linha 42

Linha 43

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

Linha 44

Linha 45

Linha 46

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

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

Linha 48

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

Linha 50

Linha 51

~~**2.3 Benefícios na utilização do TDD**~~

Linha 52

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

Linha 53

Linha 54

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

Linha 55

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

Linha 56

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

Linha 57

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

Linha 58

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

Linha 59

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

Linha 60

Linha 61

Linha 62

~~**3. Testes no framewok demoiselle**~~

Linha 63

Linha 64

~~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 65

~~Esses framewoks serão rapidamente abordados abaixo na forma de uma descrição do framework, de como e quando se deve utilizá-los durante o desenvolvimento das aplicações.~~

Linha 66

Linha 67

Linha 68

Linha 69

~~**4. JUnit**~~

Linha 70

Linha 71

~~<P> Para entendermos o JUnit precisamos entender dois conceitos fundamentais utilizados em Testes de Caixa Branca. São eles os conceitos de: Driver e Stub.</P>~~

Linha 72

Linha 73

Linha 74

Linha 75

Linha 76

Linha 77

~~**4.1 Instalação**~~

Linha 78

Linha 79

~~<dependency>~~

Linha 80

~~<groupId>junit</groupId>~~

Linha 81

~~<artifactId>junit</artifactId>~~

Linha 82

~~<version>4.5</version>~~

Linha 83

~~<scope>test</scope>~~

Linha 84

~~</dependency>~~

Linha 85

Linha 86

Linha 87

~~**5. Easymock**~~

Linha 88

~~O Easymock é uma biblioteca utilizada para para "mockar" objetos e interfaces dinamicamente.~~

Linha 89

Linha 90

~~O Easymock poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor.~~

Linha 91

Linha 92

~~**5.1 Instalação**~~

Linha 93

~~Poderá ser adicionado ao projeto pelo Maven, incluindo as seguintes dependências no pom.xml:~~

Linha 94

~~<dependency>~~

Linha 95

~~<groupId>org.easymock</groupId>~~

Linha 96

~~<artifactId>easymock</artifactId>~~

Linha 97

~~<version>2.4</version>~~

Linha 98

~~<scope>test</scope>~~

Linha 99

~~</dependency>~~

Linha 100

~~<dependency>~~

Linha 101

~~<groupId>easymock</groupId>~~

Linha 102

~~<artifactId>easymockclassextension</artifactId>~~

Linha 103

~~<version>2.2</version>~~

Linha 104

~~<scope>test</scope>~~

Linha 105

~~</dependency>~~

Linha 106

Linha 107

Linha 108

Linha 109

Linha 110

~~**6. JMockit**~~

Linha 111

Linha 112

~~O JMokit também é uma biblioteca utilizada para se escrever objetos mock para testes de classes java.~~

Linha 113

Linha 114

O JMockit poderá ser executado através dos testes realizados pelo JUnit de forma transparente para o desenvolvedor, bem como em conjunto com a utilização do Easymock e do Easymock Classextension.

Linha 115

Linha 116

~~**6.1 Instalação**~~

Linha 117

Linha 118

~~Poderá ser adicionado ao projeto pelo Maven, incluindo as seguintes dependências no pom.xml:~~

Linha 119

Linha 120

~~<dependency>~~

Linha 121

~~<groupId>mockit</groupId>~~

Linha 122

~~<artifactId>jmockit</artifactId>~~

Linha 123

~~<version>0.998</version>~~

Linha 124

~~<scope>test</scope>~~

Linha 125

~~</dependency>~~

Linha 126

Linha 127

~~Também deverão ser configurados os determinados plugins na sessão de build para garantir a correta cópia e utilização do .jar:~~

Linha 128

Linha 129

~~<plugin>~~

Linha 130

~~<artifactId>maven-dependency-plugin</artifactId>~~

Linha 131

~~<executions>~~

Linha 132

~~<execution>~~

Linha 133

~~<id>copy</id>~~

Linha 134

~~<phase>generate-test-resources</phase>~~

Linha 135

~~<goals>~~

Linha 136

~~<goal>copy</goal>~~

Linha 137

~~</goals>~~

Linha 138

~~<configuration>~~

Linha 139

~~<artifactItems>~~

Linha 140

~~<artifactItem>~~

Linha 141

~~<groupId>mockit</groupId>~~

Linha 142

~~<artifactId>jmockit</artifactId>~~

Linha 143

~~<version>0.998</version>~~

Linha 144

~~<type>jar</type>~~

Linha 145

~~<overWrite>true</overWrite>~~

Linha 146

~~<outputDirectory>${project.build.directory}</outputDirectory>~~

Linha 147

~~</artifactItem>~~

Linha 148

~~</artifactItems>~~

Linha 149

~~</configuration>~~

Linha 150

~~</execution>~~

Linha 151

~~</executions>~~

Linha 152

~~</plugin>~~

Linha 153

Linha 154

~~...~~

Linha 155

Linha 156

~~<plugin>~~

Linha 157

~~<groupId>org.apache.maven.plugins</groupId>~~

Linha 158

~~<artifactId>maven-surefire-plugin</artifactId>~~

Linha 159

~~<version>2.5</version>~~

Linha 160

~~<configuration>~~

Linha 161

~~<argLine>-javaagent:${project.build.directory}/jmockit-0.998.jar</argLine>~~

Linha 162

~~</configuration>~~

Linha 163

~~</plugin>~~

Linha 164

Linha 165

Linha 166

Linha 167

~~**7. Quando usar cada framework de testes durante o desenvolvimento dos testes unitários ?**~~

Linha 168

Linha 169

~~**JUnit**~~

Linha 170

Linha 171

No caso dos projetos utilizando o framework demoiselle, em particular o demoiselle-crud, o JUnit já é disponibilizado juntamente com o framework, o que dispensa sua instalação prévia.

Linha 172

Linha 173

~~É interessante que dentro do projeto de testes a estrutura de pacotes do projeto principal seja mantida, para facilitar a navegação pelo desenvolvedor.~~

Linha 174

Linha 175

Linha 176

~~Exemplo:~~

Linha 177

~~método principal a ser testado: public void insert()~~

Linha 178

}

Linha 179

Linha 180

Linha 181

~~O JUnit será utilizado para todos os casos de testes do projeto, inclusive os que utilizam o Easymock, Easymock classextendion e o JMockit, ou a combinação deles.~~

Linha 182

Linha 183

~~**Easymock**~~

Linha 184

~~No caso das bibliotecas do Easymock existirá um emprego específico do Easymock ou do Easymock Classextension dependendo do foco do teste.~~

Linha 185

Para o caso de haver a necessidade de se mockar uma interface, deverá ser utilizado o Easymock. Já para os casos de haver a necessidade de mockar classes, o classextension será o indicado.

Linha 186

Linha 187

Linha 188

~~A utilização do Easymock também é interessante quando se quer definir um valor fixo para o retorno do método que está sendo mockado.~~

Linha 189

~~Uma limitação para a utilização do Easymock é a impossibilidade de se mockar métodos privados, estáticos e finais das classes.~~

Linha 190

~~Segue abaixo um exemplo de utilização do Easymock nos testes das classes do demoiselle-crud.~~

Linha 191

~~A classe sob testes é a MessageDecorator e o método que se deseja testar especificamente dessa classe é o método getLocale()~~

Linha 192

~~Para essa caso foi criada uma classe CrudMessageDecoratorTest para a realização dos casos de testes. Veja classe abaixo.~~

Linha 193

Linha 194

}

Linha 195

Linha 196

~~private ICrudMessage crudMessage;~~

Linha 197

Linha 198

/**

Linha 199

* Initialize test class creating a mock object from ICrudMessage interface

Linha 200

Linha 201

Linha 202

Linha 203

~~@Before~~

Linha 204

~~public void setUp() throws Exception {~~

Linha 205

Linha 206

~~crudMessage = EasyMock.createMock(ICrudMessage.class);~~

Linha 207

~~EasyMock.expect(crudMessage.getLabel()).andReturn("myLabel").anyTimes();~~

Linha 208

~~String key = "crud.message.ok";~~

Linha 209

~~EasyMock.expect(crudMessage.getKey()).andReturn(key).anyTimes();~~

Linha 210

~~EasyMock.expect(crudMessage.getCustomPattern()).andReturn(key.replaceAll("crud.", "app.myMB.")).anyTimes();~~

Linha 211

~~Locale loc = new Locale("pt", "Br");~~

Linha 212

~~EasyMock.expect(crudMessage.getLocale()).andReturn(loc).anyTimes();~~

Linha 213

~~EasyMock.expect(crudMessage.getResourceName()).andReturn("META-INF/crud-messages").anyTimes();~~

Linha 214

~~EasyMock.expect(crudMessage.getAppResourceName()).andReturn("messages").anyTimes();~~

Linha 215

~~EasyMock.expect(crudMessage.getSeverity()).andReturn(Severity.ERROR).anyTimes();~~

Linha 216

Linha 217

~~EasyMock.replay(crudMessage);~~

Linha 218

Linha 219

}

Linha 220

Linha 221

Linha 222

~~@Test~~

Linha 223

~~public void testGetLocale() {~~

Linha 224

~~MessageDecorator msgDecorator = new MessageDecorator(crudMessage, "test");~~

Linha 225

~~Assert.assertEquals("pt_BR", msgDecorator.getLocale().toString());~~

Linha 226

}

Linha 227

Linha 228

}

Linha 229

Linha 230

Linha 231

Linha 232

~~**JMockit**~~

Linha 233

Linha 234

~~No caso de uso do JMockit não implica a não utilização do Easymock, pelo contrário, poderemos utilizar um mix das duas soluções em conjunto.~~

Linha 235

~~Exemplo de utilização do JMockit juntamente com Easymock.~~

Linha 236

~~A classe sob testes é a ResourceBundleManager e os métodos em testes são getMessage() e getCurrentLoader().~~

Linha 237

Linha 238

Linha 239

~~public class ResourceBundleManagerTest extends TestCase {~~

Linha 240

Linha 241

~~private ResourceBundleManager bm = null;~~

Linha 242

Linha 243

Linha 244

~~public static abstract class MockFacesContext~~

Linha 245

{

Linha 246

Linha 247

~~@Mock~~

Linha 248

}

Linha 249

~~FacesContext ctx = EasyMock.createMock(FacesContext.class);~~

Linha 250

~~Application app = EasyMock.createMock(Application.class);~~

Linha 251

~~ELContext ectx = EasyMock.createMock(ELContext.class);~~

Linha 252

~~ValueExpression vexp = EasyMock.createMock(ValueExpression.class);~~

Linha 253

~~EasyMock.expect(vexp.getValue(EasyMock.isA(ELContext.class))).andReturn("test");~~

Linha 254

Linha 255

~~EasyMock.replay(vexp);~~

Linha 256

~~EasyMock.replay(ectx);~~

Linha 257

Linha 258

~~ExpressionFactory exf = EasyMock.createMock(ExpressionFactory.class);~~

Linha 259

~~EasyMock.expect(exf.createValueExpression(EasyMock.isA(ELContext.class), EasyMock.isA(String.class),EasyMock.isA(Class.class))).andReturn(vexp);~~

Linha 260

~~EasyMock.replay(exf);~~

Linha 261

Linha 262

Linha 263

~~EasyMock.expect(app.getExpressionFactory()).andReturn(exf);~~

Linha 264

~~EasyMock.replay(app);~~

Linha 265

Linha 266

~~EasyMock.expect(ctx.getApplication()).andReturn(app);~~

Linha 267

~~EasyMock.expect(ctx.getELContext()).andReturn(ectx);~~

Linha 268

~~EasyMock.replay(ctx);~~

Linha 269

Linha 270

~~return ctx;~~

Linha 271

}

Linha 272

Linha 273

}

Linha 274

Linha 275

~~public void setUp(){~~

Linha 276

~~bm = new ResourceBundleManager();~~

Linha 277

}

Linha 278

Linha 279

~~public void testGetMessageFromResourceBundle(){~~

Linha 280

~~Mockit.setUpMock(FacesContext.class, MockFacesContext.class);~~

Linha 281

~~String msg = bm.getMessage("test");~~

Linha 282

~~assertEquals("test", msg);~~

Linha 283

}

Linha 284

Linha 285

~~public void testGetCurrentLoader(){~~

Linha 286

~~NoLayers nl = new NoLayers();~~

Linha 287

~~ClassLoader loader = bm.getCurrentLoader((Object)nl);~~

Linha 288

~~assertNotNull(loader);~~

Linha 289

}

Linha 290

Linha 291

}

Linha 292

Orientações técnicas/Práticas de Testes 2.9 (Edição mínima)

2013-01-09T20:00:40Z

Linha 6

* [[Orientações técnicas/Conceitos Gerais Testes Unitarios | Conceitos Gerais de Testes Unitários]]

* [[Orientações técnicas/Melhores Praticas | Melhores Práticas]]

* [[Orientações técnicas/Conceitos Gerais Testes Unitarios | Conceitos Gerais de Testes Unitários]]

Linha 10

* [[Orientações técnicas/Quando Usar Framework Testes | Quando utilizar cada framework de Testes]]

* [[Orientações técnicas/Recomendacoes Programacao Orientada Testes | Recomendações para uma programação orientada a testes]]