Tutorial JUnit

Equipe: Pyxis Solutions IFSP - A6PGP

São Paulo 21 de Agosto de 2017.

Objetivo 4

O que é o JUnit? 4

Observações 4

Anotações 5

Estrutura do JUnit 7

Utilizando o JUnit durante os testes 9

JaCoCo 13

Referências 14

Versão: Autor Versão Descrição

Arion Melkan 1.0 Criação do documento

Arion Melkan 1.1 Revisão do conteúdo Jacoco

Objetivo Capacitar a equipe Pyxis Solutions a trabalhar com o framework JUnit.

O que é o JUnit? O JUnit é um framework que disponibiliza um conjunto de classes, para

aplicações java, com o objetivo de automatizar os testes dos desenvolvedores. Isto não significa que os desenvolvedores poderão se preocupar em somente programar e os testes serão criados “sozinhos”.

Observa-se que com a utilização do JUnit, usa-se o conceito TDD (Test Driven Developer) e as principais vantagens desse conceito são:

1. Cada funcionalidade que o programador desenvolver será validada. Ou seja, evita do desenvolvedor programar tudo e depois perder um tempo refazendo diversas funcionalidades por causa de um determinado erro;

2. Entra o conceito de refatoração, o desenvolvedor não se preocupará que o seu teste inicial dê erro, aliás isto é importante que aconteça. E depois da implementação da funcionalidade, o método, deve passar naquele teste. Desse modo, o desenvolvimento sofrerá refatorações até chegar a um escopo que a funcionalidade atenda a proposta;

3. Garante confiabilidade e qualidade no desenvolvimento do sistema, pois confirma o que foi testado antes mesmo de passar o código para o ambiente de produção, por exemplo;

Portanto a utilização do JUnit traz uma maior eficiência, produtividade e qualidade nos códigos desenvolvidos.

Observações Geralmente o JUnit vem agregado em algumas IDEs, no caso: Eclipse, STS

(Spring Tools Suite), entre outros…

Sendo assim, não há necessidade de instalá-lo manualmente!

Mas caso queiram ver a instalação do JUnit, recomendam-se estes dois links:

● https://www.youtube.com/watch?v=AzQGk-j0E34 ● https://www.youtube.com/watch?v=2nWI8wZM-U0

São vídeos para uma introdução, mas que servem para auxiliá-lo(a) durante uma instalação e um conhecimento sobre este framework.

Anotações Neste tópico o núcleo do assunto é mostrar as principais anotações do JUnit.

As anotações têm por objetivo dar informações sobre um código ou programa escrito e por isso, assemelham-se aos comentários. Porém, as anotações podem ser interpretadas por compiladores, adicionando certas funções que automatizam ou facilitam algumas tarefas. Podem ser utilizadas para informar ao compilador para suprimir avisos e mensagens de erro, gerar código (XML) e executar testes. No JUnit, as principais anotações são:

● @SpringBootTest: Esta anotação diz ao Spring Boot para procurar uma classe de configuração principal (uma com @SpringBootApplication, por exemplo) e usá-la para iniciar um contexto de aplicativo Spring;

● @RunWith: Invoca uma classe (que contém rotinas de testes) para a realização de testes sobre uma determinada classe. O JUnit possui sua própria classe de testes (JUnit Core) que contém vários métodos, mas também permite que o desenvolvedor escreva uma classe com métodos de testes personalizados, inclusive com métodos escritos por ele;

● @Test: Esta anotação define a execução de um método em modo de teste. Para executar o método, primeiro o JUnit constrói uma nova instância da classe e então invoca o método anotado. Quaisquer exceções lançadas pelo teste serão relatadas pelo JUnit como uma falha. Se nenhuma exceção for lançada, o teste é finalizado como concluído com sucesso. Também suporta dois parâmetros opcionais: expected e timeout. O parâmetro expected declara que o retorno de um método deve ser uma exceção. Desta forma, se o método não retorna uma exceção ou de ela é diferente da que foi declarada, o teste é considerado com falha. Por exemplo:

@Test(expected=IndexOutOfBoundsException.class) public void outOfBounds() { new ArrayList<Object>().get(1); }

Deverá ser executado com sucesso.

O parâmetro timeout especifica o tempo máximo de execução de um teste. Se ele demorar mais do que o especificado, o teste é considerado como falha. Por exemplo:

@Test(timeout=100) public void infinity() { while(true); }

Deverá ser considerado como falha.

Imagem 01: Estrutura dos métodos outOfBouns e infinity;

Imagem 02: Resultado da execução dos métodos da primeira imagem;

Observa-se, na imagem 02, que o método outOfBounds executou com sucesso e o método infinity não executou com sucesso.

Estrutura do JUnit

Neste tópico a abordagem do tutorial é o foco da estrutura do JUnit num projeto de sistema.

Imagem 02: Estrutura de diretório, pacote e classe do JUnit;

Percebe-se que dentro do diretório da aplicação, os códigos de testes desenvolvidos no JUnit são guardados/salvados numa classe que possui o mesmo nome da classe da aplicação, no entanto inclui-se o nome teste. Desse modo, atente-se, também, que o pacote se encontra numa pasta java, entretanto esta pasta está dentro da pasta test e, por sua vez, está na pasta src.

Estas dicas são essenciais para um desenvolvimento de trabalho digno, pois mantendo uma estrutura segundo a imagem 02, a equipe de desenvolvimento deixa de contar com a sorte e potencializa a qualidade da entrega final do projeto.

Imagem 03: Estrutura da classe do JUnit;

Observa-se na imagem 03 que a estrutura de uma classe de testes, possui algumas importações. Destacam-se as importações das anotações: Test, SpringBootTest, RunWith e o SpringRunner.

Este será o padrão utilizado em todas as classes de testes criadas, portanto o usuário necessitará seguí-lo.

Imagem 04: Classe UtilSocketTest com os métodos de testes declarados;

Repare-se que foram criados diversos métodos para os seguintes cenários:

● Fluxo perfeito, quando a aplicação gera o retorno que é o correto, esperado; ● Fluxo com exceção, quando a aplicação gera alguma exceção esperada;

Este método com exceção serve para os demais serviços.

Utilizando o JUnit durante os testes A intenção deste tópico é discorrer sobre a utilização do JUnit durante a

execução dos testes.

Imagem 05: Exemplo de uma execução da classe de teste.

Imagem 06: Exemplo de uma execução de teste ocorrida com sucesso;

Atente-se que a imagem 05 exibe um exemplo de método que validará a funcionalidade, método, que o desenvolvedor criará.

O que seja, realmente, interessante em mostrar é que dentro do método existe uma classe chamada: assertTrue. Esta classe, junto com os métodos, permitem diversas maneiras de serem implementadas. Na classe de exemplo, obtém-se um teste com o assertTrue, isto faz com a resposta esperada seja validada com a resposta atual, mesmo estando diferentes.

O intuito de colocar um assertTrue foi mostrar que o teste executado passou, de acordo com a imagem 06.

Imagem 07: Estatística de execução dos testes em JUnit.

Repare-se que o JUnit possui uma área que mostra as estatísticas geradas após a execução dos testes, conforme imagem 07.

No caso, a barra vinho demonstra que houve algum erro ou alguma falha. Pela imagem 07 aconteceu uma falha num dos métodos e outro foi executado com sucesso dentro da classe LibraryTest.

Imagem 08: Amostra de testes construídos;

Repare-se que dentro da classe WordFinderTest possui métodos que esperam algumas exceções, por exemplo: Null pointer exception.

É relevante ressaltar que durante a criação dos testes é de suma importância criar métodos que validem exceções. Até para analisar se um determinado método implementa o try/catch ou se ele repassa, throw, para quem o chamou.

No caso da imagem 08, tem-se métodos com a validação de exceção, null pointer exception, quando o texto é nulo, ou quando uma letra é nula.

Imagem 09: Amostra de outros testes construídos na classe WordFinderTest;

Observa-se que existem outros métodos que fazem a validação desde encontrar a primeira letra, como encontrar a “maior” letra dentro de um array. Segundo imagem 09.

Imagem 10: Execução dos testes, na classe WordFinderTest, com sucesso;

A estatística gerada na classe WordFinderTest, imagem 10, mostra que foram executados oito (8) métodos e todos foram executados com sucesso.

Imagem 11: Amostra de métodos, test, da classe PalindromeCheckTest;

Imagem 12: Execução com sucesso da classe PalindromeCheckTest;

Nas imagens 11 e 12 exemplificam os testes construídos e feitos na classe PalindromeCheckTest. Observa-se que todos os testes construídos foram executados com sucesso.

JaCoCo Tópico que discorre um pouco sobre JaCoCo.

Resumidamente, o JaCoCo é uma ferramenta que traz cobertura nos testes realizados no JUnit, trazendo métricas de conclusão a cerca dos testes feitos ou não.

Se caso não houvesse o maven ou o gradle, opte pela seguinte instalação:

Imagem 12: Instalação do plugin EcliEmma Java Code Coverage;

A imagem 12 mostra a tela do install new software com a opção de instalar o plugin EclEmma Java Code Coverage.

Observa-se que a busca foi feita por JaCoCo no site: Oxygen.

http://download.eclipse.org/releases/Oxygen

O usuário pode optar a instalação através da tela Eclipse Marketplace.

Imagem 13: Cobertura dos testes com JaCoCo;

De acordo com a imagem 13 a cobertura dos testes foi 80,8%;

LEMBRE-SE: ESTE NÃO É O SEU CASO, POIS EXISTE O GRADLE.

A esta altura o arquivo build.gradle já está configurado, portanto a execução do Jacoco fica mais simples e com dois comandos resolve esta situação.

Imagem 14: Visualização de uma parte da configuração do jacoco no build.gradle;

A imagem 14 contém, apenas, para exibição uma parte da configuração do jacoco no arquivo gradle.

Imagem 15: Opção do Run As no projeto Dedicatories;

De acordo com a imagem 15, necessita pressionar com o botão direito em cima do projeto, Dedicatories no caso, e selecionar a opção Run As e Run Configurations…

A partir dessa seleção, procure Gradle Project e pressione duas vezes. Isto abrirá um new_configuration, conforme a imagem 15.

Faça as seguintes modificações:

● Gradle Tasks: Escreva clean build; Isto faz com que o gradle verifique as modificações do seu arquivo e as instale.

● Working Directory: Escolha o diretório do Dedicatories; ● name: Caso mude o name, o nome deixará de ser new_configuration para

outro nome qualquer, neste exemplo está clean build;

Depois das configurações, aperte Run. Após o término do run, dentro da pasta build, que está no diretório Dedicatories, haverá a pasta Jacoco, conforme imagem 16.

Imagem 16: Pasta jacoco dentro da pasta build;

Mas ainda não terminou, necessita criar outra Run Configuration do gradle para configurar os tests reports do jacoco.

Faça conforme o procedimento na imagem 15, escreva o name, para não confundir com o que já existe, e, principalmente, escreva um novo comando no gradle task, isso é muito importante!

● Gradle Task: Escreva clean build jacocoTestReport;

Feito as configurações, execute Run. Após o término, deverá estar de acordo com a imagem 17.

Imagem 17: jacocoTestReport build com sucesso;

Pronto, está finalizado!

Para verificar o arquivo html, acesse o caminho:

\Dedicatories\build\reports\jacoco\test\html

Selecione o arquivo index.html, conforme imagem 18.

Imagem 18: Resultado da cobertura de testes através de uma página HTML;

Referências

● https://www.youtube.com/watch?v=r-CbsG7x0h8 ● http://www.devmedia.com.br/entendendo-anotacoes-em-java/26772 ● http://www.tiexpert.net/programacao/java/annotations.php ● http://junit.sourceforge.net/javadoc/org/junit/Test.html ● http://tdd.caelum.com.br/ ● https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-te

sting.html