Testes Unitários

243 visualizações

Publicada em

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Testes Unitários

  1. 1. Ruither Borba, o delki8 about.me/delki8 Testes Unitarios todo código é culpado até que se prove o contrário
  2. 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. 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. 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. 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. 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. 7. Ruither Borba, o delki8 about.me/delki8 Piramides de testes
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Ruither Borba, o delki8 about.me/delki8 Duvidas?
  23. 23. Ruither Borba, o delki8 about.me/delki8 Recomende ∆ Recomende no Linkedin ∆ Curta no slideshare ∆ Curta no about.me

×