JUnit Experience

Post on 11-Jun-2015

918 views 3 download

description

Uma experiência de implementação de testes unitários usando JUnit 4. Entendendo como testes unitários podem ajudar na evolução do código, e como podemos construindo testes unitários melhores.

Transcript of JUnit Experience

ExperienceConstruindo testes unitários usando JUnit 4

Problemas com bugs?

Testes unitários podem rastreá-los!!!

O JUnit se preocupa em monitorar comportamentos do código

Quando um teste falha,…

é sinal de que precisamos evoluir o código

Geralmente começamos com testes “felizes”…

como por exemplo comparar o resultado de um comportamento com um valor esperado…,

e torcer pra que tudo dê certo!!!

Testes bem construídos garantem uma evolução segura do software

Comportamentos estranhos inseridos no código serão rapidamente identificados

Os casos negativos também são importantes!!!

O importante é tentar identificar o máximo de cenários possíveis, e representar isso através de testes unitários.

Não vamos esquecer das Exceptions…

É importante criar testes que verifiquem a ocorrência de exceções…

pois se o teste quebrar, temos como mapear a origem do problema.

À medida que vamos evoluindo o código, os testes começam a ficar um pouco mais volumosos.

Imagine um teste que cadastra 5 usuários para verificar se eles estão sendo persistidos. Que trabalhera!!!

Já ouviu falar em Data Builders?

alguns conhecem como Fixture...

Design Pattern responsável por construir objetos de maneira rápida e descritiva

O código de antes...

E agora cadastrando 5 usuários!!!

O código…

Mostre-mepor favor!!!

1- Um objeto encapsulado

2- Um método estático que chama a fixture

3- Um método que retorna o objeto construído

4- Métodos adicionais que 'setam' os atributos no meio do caminho

5- A corrente só termina quando retorna o usuario

Ainda dá pra emagrecer mais um pouquinho, basta ter um pouco de fé…

Desse jeito fica bem mais fácil de trabalhar…

reaproveitar isso em outros testes!!!

E o melhor é que ainda dá pra…

Então chega a hora de começar a dividir responsabilidades…

Queremos implementar o acesso ao banco mas não queremos que o teste se preocupe com isso…

Então vamos deixar isso com o setUp()

@BeforeClass@Before

@After@AfterClass

Implementam comportamentos para serem utilizados…

- BeforeClass: Antes de iniciar a suite de testes- Before: Antes de executar cada teste- After: Depois de executar cada teste- AfterClass: Depois de finalizar a suite de testes

Agora temos uma camada de serviço, que implementa comportamentos

sobre Usuario…

uma camada de acesso ao banco de dados, que

persiste as informações…

e um código já bem estruturado e organizado

Mas pare ai!!!

Se eu tiver que acessar o banco de dados a cada teste que fizer, será muito demorado…

Isso não é teste unitário…

Antes de pensar na integração do sistema, precisamos garantir suas unidades!!!

Mas então como é que eu faço???

Gambiarra???

Isso se chama Mock!!!

Não…

Mock Object é um padrão de

desenvolvimento que simula

comportamentos de objetos

concretos de uma aplicação ou funcionalidade.

e em vez de acessar o banco de dados, ‘mocamos’ o comportamento com uma lista, ou simplesmente não fazemos nada…

Substituímos o UsuárioDao por um Mock Object compatível…

que sobrescrevetodos os métodos…

Desta maneira garantimos testes simples e coesos…

E fica mais fácil de manter a qualidade!!!

Quem sou eu?

Renan Uchôa,

estudante de Engenharia de Software pela Universidade Federal do Pampa,

e Desenvolvedor Java pela uMov.me Tecnologia S.A.