Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Techsync - TDD - Desenvolvimento orientado a te...

Techsync - TDD - Desenvolvimento orientado a testes

Wagner Voltz - Fusca

January 05, 2023
Tweet

More Decks by Wagner Voltz - Fusca

Other Decks in Technology

Transcript

  1. Teste para suportar o desenvolvimento - Testes automatizados - TDD

    - Shift left testing Testes para encontrar bugs - Testes manuais - BDD - Testes estruturais - Testes de fronteiras (boundaries testing) Quando usar testes?
  2. 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.
  3. 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
  4. Desculpas para não fazer TDD • Sou dev, não preciso

    testar • O prazo é curto para entregar • Nosso sistema é legado
  5. 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
  6. Como começar? 1) Comece pelos bugs (test bug developer) 2)

    Use pareto! (80 / 20) 3) o que é novo já começa com TDD 4) Metrificar e acompanhar
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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