Testes automatizado no desenvolvimento de software

Um papo sobre os fundamentos, custos e práticas dos testes automatizados

Transcript

1. Testes automatizado no desenvolvimento de software Jack Makiyama Tech Lead um papo sobre os fundamentos, custos e práticas dos testes automatizados
2. Sumário Introdução 2 Fundamentos Custo do testes automatizados para o projeto Mão na massa
3. 3 • Quem conhece testes automatizados? • Quem usa testes automatizados? • Quem nunca ouviu falar em testes automatizados?
4. Quem sou eu?
5. 5 Atuo com desenvolvimento web(backend) desde 2008, Trabalhei em algumas empresas, como: • Clickbus • Nitro2Code/Leady E em Sinop: • - TicketSys(Bilhete Agora) • - Evo Networks Também trabalhei em algumas agências/fábricas de sites em Sinop e fiz muito freela na vida. Jack Makiyama - Tech Lead - Objective
6. 6 • Arquitetura • Comunidades • Design de código • PHP • Processos ágeis • Testes automatizados Atualmente esses tem sido alguns dos temas que tenho voltado minha atenção:
7. O que é um teste? 7 Antes de tudo precisamos entender de qual teste estamos falando aqui. Acredito que toda iteração que fazemos com o software de forma a confirmar algum funcionamento é um teste. Então em um cenário ausente de testes automatizados, ao longo do desenvolvimento de uma aplicação temos sempre presente um ciclo que se repete até a finalização da atividade: • escrever um trecho de código de produção • estimular a aplicação através da interface de usuário para expressar o interesse deste código inserido.
8. 8 Podemos ver o exemplo da solução do FizzBuzz:
9. Qualidade de software 9 A qualidade de um software é um reflexo que provém da cultura da equipe que irá desenvolvê-lo e mantê-lo. Se for desenvolvido por uma equipe que tenha na sua cultura um processo voltada a boas práticas, fazendo uso de padrões e convenções de projetos muito bem conhecidas e usadas extensivamente pela comunidade de software, é provável que seu software terá menos bugs que uma equipe que tem a cultura que promove apenas um grande volume de entregas e esses com prazos duvidosos.
10. 10 Algumas preocupações que podem contribuir para o aumento da qualidade de software: • Design estratégico • Arquitetura • Testes automatizados • Análise estática de código • CI/CD • Code Reviews • SOLID • Design Pattern • Documentações
11. Onde entra a automatização? 11 Como qualquer tipo de automação, no desenvolvimento de software também automatizamos para poupar o esforço físico que resultaria da repetição de uma ação humana. Padronizamos o fluxo das informações de cada ação que se repete para representar suas intenções em forma de código de testes na aplicação.
12. Contras 12 • Sem o mindset dos testes automatizados parece que não rende o trabalho • Criar a base de código do testes do zero é onerosa • Difícil de aplicar em códigos legados
13. Prós 13 • Garantia de que o que existe está realmente funcionando • Segurança em fazer manutenção ou adicionar novas features • Antecipação de possíveis bugs • Os testes exigem um bom design de código • Tendem a guiar o desenvolvimento • Servem para documentar o funcionamento de um contexto
14. Software feito para durar, como os testes contribuem para a longevidade de um software? 14 A menos que você esteja fazendo uma PoC, você irá precisar dar suporte para a sua aplicação, não apenas você dará suporte, mas também outros membros da equipe que você participa. Tendo isso em mente não podemos apenas adicionar novas features de acordo com a exigência do cliente, precisamos ter em mente que sempre virá mudanças de requisitos e temos que garantir que o crescimento e a sustentação da base de código se mantenham sob controle e continue entregando os resultados esperados para seus consumidores. Os testes automatizados além de garantir o funcionamento de um determinado contexto também promove o uso de boas práticas para programarmos para abstrações e contratos ao invés de grandes implementações e estimula uso de um bom design de código.
15. O que precisamos então ter em mente para começarmos a usar testes automatizados? 15 Acredito que precisamos inicialmente ter em mente a forma que olhamos para a aplicação para entender o intuito dos testes que vamos automatizar. Podemos considerar duas formas de olhar para a aplicação pensando em testes, que seria quando conhecemos o comportamento interno do código que chamamos de White Box e chamamos de Black Box quando temos apenas conhecimento da API pública de uma aplicação.
16. White Box 16 Onde temos conhecimento do funcionamento interno do código e com o uso de testes unitários ou integração podemos influenciar a aplicação resolver uma tarefa com valores previamente injetados ou esperar que um método de uma dependência seja estimulado, focando em pequenos contextos.
17. Black Box 17 Onde não temos conhecimento do funcionamento interno do código, olhamos para as interfaces de usuário da aplicação e geralmente são usados testes que descrevem comportamentos, testes de tela e testes de ponta a ponta(e2e).
18. Pirâmide dos testes 18 Imagem retirada do artigo A PIRÂMIDE DE AUTOMAÇÃO DE TESTES no portal Tecnisys: http://www.tecnisys.com.br/noticias/2019/a-piramide-de-automacao-de-testes
19. Testes Unitário 19 • Cada método público deve ter pelo menos um teste para cada fluxo conhecido • Um teste não pode ter dependência de outros testes • Em um teste fazemos mocks das dependências do método alvo para induzir um comportamento esperado e comprovar nossas expectativas • Testes unitários sempre irão exigir um bom design de código.
20. Testes de Integração 20 Com intuito de garantir o funcionamento do fluxo de um serviço, os testes de integração oferecem uma boa relação entre uma menor verbosidade referente aos testes unitários e a garantia de que as unidades interagem corretamente. Tendo sempre a premissa de que se não temos testes unitários, devemos no mínimo ter um teste de integração.
21. Testes de Aceitação 21 • Geralmente focado na interface de usuário com o intuito de comprovar que os requisitos de uma demanda está garantida. • Testes e2e sempre irão exigir um bom funcionamento das features de acordo com os requisitos funcionais do software.
22. Testes de código 22 São os testes mais usados onde estimulamos diretamente o código que estamos desenvolvendo com um framework de testes tipo o PHPUnit do PHP ou Jest do JavaScript.
23. Padrão Triple A 23 É muito utilizado o padrão Triple A onde promove a organização em: • Arrange para levantarmos as dependências do teste • Act onde estimulamos o alvo do nosso teste • Assert onde fazemos as asserções que esperamos.
24. Testes de comportamento 24 São os testes focado em descrever o comportamento da nossa aplicação, muita das vez é incorporado nos testes de código, mas também podemos usar ferramentas dedicadas a esse estilo de teste, por exemplo a conhecida sintaxe Gherkin que é uma DSL usando as palavras chaves: Given, When, Them.
25. TDD 25 Imagem retirada do artigo Afinal, o que é TDD? no portal treinaweb: https://www.treinaweb.com.br/blog/afinal-o-que-e-tdd
26. Qual é o custo para o projeto em automatizar seus testes? 26
27. 27 Quem já escutou frases semelhantes a essas: • "Meu chefe não deixa usar testes automatizados" • "Faço testes em produção" • "Minha equipe não faz uso de testes" • "Temos um QA na equipe para fazer os testes" • "Escrever testes faz demorar mais para entregar a feature"
28. 28 Eu já tive que escutar todo tipo de variação dessas frases, desde gestores evitando um possível tempo maior de desenvolvimento, custo adicional não previsto ou mesmo achando que iria economizar sem esses testes. Até desenvolvedores que não tinham conhecimento sobre testes automatizados que preferiam o apego em continuar na zona de conforto. Por isso precisamos ter uma noção de como mostrar o valor dos testes automatizados, mas sem colocá-los como uma venda casada que seria um custo a mais que demoraria mais tempo de desenvolvimento por causa deles e sim entregar códigos testados de fato.
29. Como atuar sendo: 29 Júnior ◦ Onde é esperado que esteja aprendendo sobre testes, mas infelizmente é o momento da carreira mais difícil de influenciar uma equipe, mas claro que não deve deixar de ser feito. O ideal é focar em praticar testes automatizados como estudo fora do trabalho, resolver problemas propostos no formato de Dojos e levar exemplos de como essa prática fora do trabalho tem feito sentido e como poderia melhorar os projetos da empresa.
30. Como atuar sendo: 30 Pleno ◦ Deveria já ter uma noção prática de testes automatizados, mesmo precisando de suporte de um senior em alguns casos mais complexos, mas já poderia se arriscar a entregar pequenos contextos com testes e buscar defender a motivação de entregar códigos com testes automatizados para tentar influenciar a equipe.
31. Como atuar sendo: 31 Senior ◦ Se você não está entregando códigos com testes automatizados, eu vou duvidar da sua senioridade. No mínimo você deveria incomodar a equipe inteira pela ausência de testes no projeto.
32. E como usar testes automatizados? 32 Você e a equipe: • O primeiro passo com certeza é a conscientização, é preciso falar sobre testes, fomentar a ideia e praticar os testes junto com a equipe para passar a fazer parte do mindset da equipe. • Promover sessões de Dojos para criar uma consciência coletiva de como fluir com os testes. • Evidenciar partes do sistema onde faria sentido ter um teste • Promover código testado
33. E como usar testes automatizados? 33 Sistema legado • Tentar cobrir os principais fluxos com testes de ponta a ponta(e2e). • Fazer uso de Pull Requests e Code review para não deixar mais entrar código sem testes. • Cobrir de testes o que precisar alterar para garantir que a sua alteração não vai implementar novos bugs.
34. E como usar testes automatizados? 34 Sistema do zero • Aqui é um pouco mais fácil, pois podemos começar a construção do projeto já pensando em testes automatizados, assim já definindo as convenções para fazer os testes serem parte do processo de desenvolvimento.
35. E como usar testes automatizados? 35 Ferramental • Framework de testes • CI/CD • Code Coverage
36. Vamos para a prática!
37. Obrigado!
38. SÃO PAULO | SP Rua Peixoto Gomide, 996 6º andar | Cerqueira César CEP: 01409-000 +55 11 3176-8100 CURITIBA | PR Av. João Gualberto, 1740 9º andar | Juvevê CEP: 80030-001 +55 41 3122-9100 MARINGÁ | PR Av. Horácio Raccanelo Filho, 5355 Sala 1 | Zona 7 CEP: 87020-035 +55 44 3032-9150 CHICAGO | IL | USA 222 Merchandise Mart Plaza Suite 1225 | Chicago | Illinois 60654 +1 312 885-7619