O documento discute testes unitários, apresentando suas vantagens, ferramentas como JUnit e Mockito, padrões para escrever testes e técnicas como TDD. É explicado o que são mocks e como eles se comportam, além de boas práticas como escrever testes para código legado.

1. Ruither Borba, o delki8
about.me/delki8
Testes Unitarios
todo código é culpado
até que se prove o contrário

2. Ruither Borba, o delki8
about.me/delki8
Porque testar?
∆ Porque todo desenvolvedor precisa de uma
forma de garantir a qualidade do que se
escreve. Testes unitários são a forma mais
rápida e prática de testar código.
∆ Porque todo projeto de software precisa
de uma forma repetível de assegurar o
funcionamento de suas funcionalidades,
mesmo depois de muito tempo.

3. Ruither Borba, o delki8
about.me/delki8
Ferramentas
∆ jUnit: Principal framework para
escrita e execução de testes com
Java.
∆ Mockito: Framework para criar
objetos com comportamento controlado
que substituem as dependências da
classe a ser testada (mocks).

4. Ruither Borba, o delki8
about.me/delki8
Ferramentas
∆ Eclemma: Plugin para Eclipse que
serve para avaliarmos de forma
visual quais as partes do nosso
código foram chamadas durante a
execução dos testes.

5. Ruither Borba, o delki8
about.me/delki8
padroes
∆ Nome da classe de testes:
◊
ClasseNegocioBOUT
∆ Onde por a classe de testes:
◊
src/test/java/pacote.classe.negocio
∆ Nome do método de teste:
◊
testMetodoComDescricaoDaChamada()

6. Ruither Borba, o delki8
about.me/delki8
O que testar?
∆ Controlador: testado pela
automação com Selenium.
∆ Negócio: testado através de testes
unitários com mocks.
∆ Persistência: testado através de
testes unitários sem mocks.

7. Ruither Borba, o delki8
about.me/delki8
Piramides de testes

8. Ruither Borba, o delki8
about.me/delki8
mock?
∆ Mocks são objetos de comportamento
altamente controlado com interfaces
idênticas às classes usadas durante
sua instanciação e substituem as
dependências da classe testada
durante a execução dos testes.

9. Ruither Borba, o delki8
about.me/delki8
Como um mock se
comporta
∆ As chamadas aos métodos de um mock
sempre retornam null a menos que o
retorno do método seja void ou que o
desenvolvedor tenha explicitamente
declarado o retorno do método durante a
fase de configuração do teste.
∆ Nesse caso, para todas as chamadas da
classe testada ao método definido, o mock
sempre vai retornar o retorno declarado.

10. Ruither Borba, o delki8
about.me/delki8
Como um mock se
comporta
∆ O mock armazena todo o histórico de
quais dos seus métodos foram chamados,
quantas vezes eles foram chamados e com
quais parâmetros esses métodos foram
chamados.
∆ Com esse histórico é possível auditar o
uso do mock durante a fase de avaliação do
teste e aumentar o nível de controle que o
desenvolvedor tem sobre o código testado.

11. Ruither Borba, o delki8
about.me/delki8
arquitetura
∆ Todos os nossos testes unitários
herdam de AbstractBOUT.
∆ Através de reflexão essa classe já
instancia nossa classe de negócios e
nos força a declarar as
dependências, injetando-as.

12. Ruither Borba, o delki8
about.me/delki8
arquitetura
∆ Para geração de massa de dados que
não sejam mocks, os padrões Builder e
FakeBuilder foram adotados.
∆ Esses padrões auxiliam a criação de
objetos simples e complexos e serão
muito usados nos nossos testes
unitários para a camada de
persistência.

13. Ruither Borba, o delki8
about.me/delki8
Teste com codigo legado
int reputacao = 0;
boolean testarComplexo = demonstrarComMetodoComplexo();
if (testarComplexo) {
reputacao -= 1;
} else {
reputacao += 1;
}

14. Ruither Borba, o delki8
about.me/delki8
tdd?
∆ É uma técnica de desenvolvimento que
se baseia em um ciclo de repetição
curto e simples:
◊
1 - Escreva um teste que falhe.
◊
2 - Escreva o mínimo de código possível
para o teste passar.
◊
3 - Refatore o código e execute novamente o
teste para garantir que ele ainda passa.
◊
4 – Retorne ao passo 1.

15. Ruither Borba, o delki8
about.me/delki8
Codificando com tdd
int reputacao = 0;
boolean testarComplexo = demonstrarComMetodoComplexo();
if (testarComplexo) {
reputacao -= 1;
} else {
reputacao += 1;
}

16. Ruither Borba, o delki8
about.me/delki8
Boas praticas
∆ Sempre coloque nomes significativos
nos seus métodos de teste, mesmo que
eles fiquem grandes.
∆ Não altere a visibilidade de um
método para testá-lo. Métodos privados
devem ser testados através dos métodos
públicos que os utilizam.

17. Ruither Borba, o delki8
about.me/delki8
Boas praticas
∆ Se um bug foi encontrado, antes de
corrigí-lo escreva um teste que vá pegá-
lo, caso contrário ele vai voltar.
∆ Se você quebra um teste, você é
responsável por realizar a correção (no
código ou no teste) que o faça passar.
∆ Termine o dia com um teste falhando.

18. Ruither Borba, o delki8
about.me/delki8
Boas praticas
∆ Escreva testes para o código
legado.
◊
E o que é código legado?
◊
R: De acordo com Michael Feathers no livro
“Working Effectively with Legacy Code”
(“Trabalhando Eficientemente com Código
Legado”, tradução livre) código legado é
código que não possui testes.

19. Ruither Borba, o delki8
about.me/delki8
Nem tudo sao flores
∆ Mais código para escrever.
∆ Mais código para manter.
∆ Sair da zona de conforto.

20. Ruither Borba, o delki8
about.me/delki8
Bala de Prata
∆ Teste unitário não é nem a única e
nem a mais abrangente forma de se
testar uma aplicação. Existem várias
outras formas como testes de
integração, desempenho, aceitação,
etc. Todas as formas são
complementares.

21. Ruither Borba, o delki8
about.me/delki8
Expectativas
∆ Mas ninguém escreve testes só
porque é bonito. O que esperamos:
◊
Menos defeitos relacionados ao negócio da
aplicação.
◊
Menos tempo do desenvolvedor gasto com
testes na aplicação real.
◊
Menos problemas de impacto em código
existente durante refatorações.

22. Ruither Borba, o delki8
about.me/delki8
Duvidas?

23. Ruither Borba, o delki8
about.me/delki8
Recomende
∆ Recomende no Linkedin
∆ Curta no slideshare
∆ Curta no about.me