TDD - Desenvolvimento Orientado a Testes ou teste depois do deploy?

Palestra apresentada no dia 20/05/2024 no evento QA Solidário que arrecadou dinheiro para as vítimas das enchentes no Rio Grande do Sul

Transcript

1. TDD - Desenvolvimento Orientado a Testes ou teste depois do deploy? Wagner Fusca
2. 2 wagner.voltz@objective.com.br wagnerfusca wagnerfusca_ wagnerfusca wagnerfusca.medium.com speakerdeck.com/wagnerfusca
4. Teste para suportar o desenvolvimento - Testes automatizados - Testes unitário - TDD - Test driven development - Shift left testing Testes para encontrar bugs - Testes manuais - Testes estruturais / integração / regressão - Testes de fronteiras (boundaries testing) - Pen tests Testes para validar entrega de valor: - BDD Quando usar testes?
5. TDD é uma técnica de design de código
7. Leis do TDD 1ª Lei: Você não deve escrever código em produção sem antes ter um spec falhando. 2ª Lei: Você não pode escrever mais do que um teste de unidade para fazer seu spec falhar, e não compilar é falhar. 3ª Lei: Você não pode escrever mais do que o necessário para fazer o seu teste passar.
8. TDD me deixa mais lento?
9. Benefícios TDD 1 - Melhora o design do código 2 - Segurança em alterar o código 3 - Melhora a cobertura do código 4 - Serve como documentação 5 - Código limpo / testável 6 - Melhora a qualidade
10. Testes automatizados são baratos!
11. Testes automatizados alavancam inovação
12. Desculpas para não fazer TDD • Sou dev, não preciso testar • O prazo é curto para entregar • Nosso sistema é legado
13. Um teste de unidade deve ser AAA Arrange: prepare tudo que você precisa para executar o teste Act: chame o método que está testando Assert: especifique o critério para o teste passar
14. Um teste de unidade deve ser AAA
15. Como começar? 1) Comece com testes pelos bugs 2) Use pareto! (80 / 20) 3) o que é novo já começa com TDD 4) Metrificar e acompanhar
16. https://www.teses.usp.br/teses/disponiveis/45/45134/tde-31072012-181230/publico/dissertacao.pdf
17. Alguns números e embasamentos Programadores que usam TDD na indústria produziram código que passaram em, aproximadamente, 50% mais testes caixa-preta do que o código produzido por grupos de controle que não usavam TDD. O grupo que usava TDD gastou menos tempo depurando. A complexidade dos algoritmos era muito menor e a quantidade e cobertura dos testes era maior nos códigos escritos com TDD. [Jan05] David S. Janzen. Software architecture improvement through test-driven development. Em Companion to the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications, OOPSLA ’05, páginas 240–241, New York, NY, USA, 2005. ACM. 6, 8, 31
18. Alguns números e embasamentos “Um estudo feito por Maximillien e Williams [MW03] mostrou uma redução de 40-50% na quantidade de defeitos e um impacto mínimo na produtividade quando programadores usaram TDD.” [MW03] E. Michael Maximilien e Laurie Williams. Assessing test-driven development at IBM. Em Proceedings of the 25th International Conference on Software Engineering, ICSE ’03, páginas 564–569, Washington, DC, USA, 2003. IEEE Computer Society. 6
19. Alguns números e embasamentos “Outro estudo feito por Lui e Chan [LC04] comparando dois grupos, um utilizando TDD e o outro escrevendo testes apenas após a implementação, mostrou uma redução no número de defeitos no grupo que utilizava TDD. Além disso, os defeitos que foram encontrados eram corrigidos mais rapidamente pelo grupo que utilizou TDD.” [LC04] Kim Man Lui e Keith C.C. Chan. Test driven development and software process improvement in China. Em Jutta Eckstein e Hubert Baumeister, editors, Extreme Programming and Agile Processes in Software Engineering, volume 3092 of Lecture Notes in Computer Science, páginas 219–222. Springer Berlin / Heidelberg, 2004. 6
20. Alguns números e embasamentos “O estudo feito por George e Williams [GW03] mostrou que, apesar de TDD poder reduzir inicialmente a produtividade dos desenvolvedores mais inexperientes, o código produzido passou entre 18% a 50% mais em testes caixa-preta do que códigos produzidos por grupos que não utilizavam TDD. Esse código também apresentou uma cobertura de testes entre 92% a 98%.” [GW03] Boby George e Laurie Williams. An initial investigation of test driven development in industry. Em Proceedings of the 2003 ACM symposium on Applied computing, SAC ’03, páginas 1135–1139, New York, NY, USA, 2003. ACM. 7, 8, 31
21. Alguns números e embasamentos • 87.5% dos programadores acreditam que TDD facilitou o entendimento dos requisitos • 95.8% acreditam que TDD reduziu o tempo gasto com depuração • 78% acreditam que TDD aumentou a produtividade da equipe • Entretanto, apenas 50% dos participantes disseram que TDD ajuda a diminuir o tempo de desenvolvimento. • Sobre qualidade, 92% pensam que TDD ajuda a manter um código de maior qualidade • 79% acreditam que ele promove um projeto de classes mais simples. https://www.teses.usp.br/teses/disponiveis/45/45134/tde-31072012- 181230/publico/dissertacao.pdf
22. Alguns números e embasamentos “Nagappan [BN06] conduziu estudos de caso na Microsoft e na IBM e os resultados indicaram que o número de defeitos de quatro produtos diminuiu de 40% a 90% em relação a projetos similares que não usaram TDD. Entretanto, o estudo mostrou também que TDD aumentou o tempo inicial de desenvolvimento entre 15% a 35%.” [BN06] Thirumalesh Bhat e Nachiappan Nagappan. Evaluating the efficacy of test-driven development: industrial case studies. Em Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering, ISESE ’06, páginas 356–363, New York, NY, USA, 2006. ACM. 7
23. Alguns números e embasamentos “Langr [Lan01] apontou que TDD aumenta a qualidade código, provê uma facilidade maior de manutenção e ajuda a produzir 33% mais testes comparado a abordagens tradicionais” [Lan01] J. Langr. Evolution of test and code via test-first design. http://eisc.univalle.edu.co/ materias/TPS/archivos/articulosPruebas/test_first_design.pdf, 2001. Último acesso em 01/03/2011. 7, 8
24. 24 wagner.voltz@objective.com.br wagnerfusca wagnerfusca_ wagnerfusca wagnerfusca.medium.com speakerdeck.com/wagnerfusca http://bit.ly/formfusca Feedback
25. 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