Testes Automatizados

Praticando e aprendendo

Transcript

1. Vizir: Testes Automatizados Testes Automatizados Praticando e aprendendo
2. Prática Vizir: Testes Automatizados
3. 2 exemplos • Lógica pura: utilizando TDD • Integrando com a API do Bitbucket: criando testes de integração Prática
4. Exemplo 1 Dada a quantidade de arquivos modificados de um pull request, ele terá um indicativo de tamanho, de acordo com as regras abaixo: - até 5 arquivos: tamanho P - até 15 arquivos: tamanho M - até 30 arquivos: tamanho G - mais de 30 arquivos: tamanho GG
5. Exemplo 2 Consumir a API do Bitbucket para retornar os Pull Requests de um projeto Detalhes: - Usaremos a autenticação via Basic Auth
6. Conceitos Vizir: Testes Automatizados
7. Os níveis de testes • Unitário: a nível de classe, dependências externas são mockadas • Integração: a nível de camadas, dependências de camadas que não são o alvo de teste, são mockadas • Sistema/Aceitação: a nível do SUT (system under test), simulando um consumidor e sem mocks Vamos falar sobre Testes? Unitário Integração Sistema
8. Uma visão prática dos níveis de teste Os níveis de testes Handlers Commands Entities Domain Services Infra Services Repositories Microservice Unit Integration System
9. Uma visão prática dos níveis de teste Os níveis de testes Handlers Commands Entities Domain Services Infra Services Repositories Microservice Unit Integration System Com o banco de dados Com a API de testes ou com a API mockada (ex: subindo uma instância dummy dela localmente)
10. Como iniciar? Vizir: Testes Automatizados
11. Em questão de nível de teste • Sistema legado: top-down • Sistema novo: bottom-up Como iniciar? Unitário Integração Sistema Sistema legado Sistema novo
12. Em questão do que testar Como iniciar? • Sistema legado: ◦ Pelos módulos/partes mais críticas ou que dão maiores problemas/manutenção • Sistema novo: ◦ Pelos módulos mais estáveis, em questão de definição de negócio
13. A estrutura de um teste Vizir: Testes Automatizados
14. 3 partes • Dado um cenário: given • Quando uma ação executar: when • Então tão resultado irá ocorrer: then A estrutura de um teste
15. Mocks Vizir: Testes Automatizados
16. Quando mocks são necessários? • Nos testes de unitários e de integração, para diminuir a complexidade dos testes e torná-los mais objetivos • Uma extensiva dependência de mocks e principalmente, de mais de um mock, é um “smell” que nossa implementação está muito acoplada Mocks
17. Cobertura de testes
18. Sobre o que é • Identificar quais linhas/arquivos não estão sendo executados • Uma primeira métrica e ferramenta para testar melhor, respondendo a pergunta, quais códigos não estão sendo testados? (mas não o inverso - ???) • 100% de cobertura não é o mais importante (ex: o Coverage.py tem 94%) Cobertura de testes
19. TDD Vizir: Testes Automatizados
20. Desmistificando o TDD TDD • O foco é na modelagem, os testes são apenas um resultado do seu uso • Uma das práticas ágeis mais difíceis de aplicar
21. Desmistificando o TDD TDD • O foco é na modelagem, os testes são apenas um resultado do seu uso • Uma das práticas ágeis mais difíceis de aplicar ◦ Não temos fluência no ferramental de testes e testes em si ◦ Não temos ideia da implementação ▪ Seja por questões arquiteturais ▪ Ou por indefinições de negócio
22. Desmistificando o TDD TDD • Quando usar então? ◦ Nossa recomendação é quando o código a ser criado possui uma lógica complexa e conhecida (ex: algoritmos de validação e parse)
23. Desmistificando o TDD TDD • Quando usar então? ◦ Nossa recomendação é quando o código a ser criado possui uma lógica complexa e conhecida (ex: algoritmos de validação e parse) • Lembre-se: ◦ Não usar TDD !== de não testar ◦ A criação de testes automatizados deve fazer parte do conceito de done do time
24. Check-list para um bom teste Vizir: Testes Automatizados
25. Check-list para um bom teste • Usar fixtures ◦ No teste modificar apenas o que for necessário para o teste (ex: um atributo de status) • Teste ser atômico ◦ Tudo que precisa de entrada, deve ser criado no teste, ou no before, e após a execução remover o que foi criado, usando o after • Testar a interface não a implementação Check-list para um bom teste
26. Check-list para um bom teste • Dar bons nomes aos testes ◦ Nome do teste deve seguir o padrão: “[ocorre comportamento X] [no estado Y]”, sempre tentando pensar mais no cenário de negócio, do que nos detalhes da implementação • Realizar assertions específicas ◦ A assertion tem que ser o mais profunda for possível. Podendo realizar mais uma assert por teste (do mesmo ouput), onde é recomendado a profundidade ir aumentando a cada assert, portanto, se tivemos 3 assertions no mesmo teste, a última será a mais profunda Check-list para um bom teste
27. Check-list para um bom teste • Usar o mínimo de mocks (de preferência não usar) ◦ Muitos mocks = implementação está muito acoplada ◦ Não mockar o que não te pertencer, ou o que for alvo do teste ◦ Não implementar detalhes de implementação nos mocks Check-list para um bom teste
28. Recomendações para aprofundar no assunto Vizir: Testes Automatizados
29. Obrigado Vizir: Testes Automatizados