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

TDC 2016 SP - Desmistificando cobertura de código como métrica de qualidade

TDC 2016 SP - Desmistificando cobertura de código como métrica de qualidade

Palestra apresentada no segundo dia da trilha de Testes (Testes II) no TDC 2016 São Paulo, no dia 09/07

Stefan Teixeira

July 09, 2016
Tweet

More Decks by Stefan Teixeira

Other Decks in Programming

Transcript

  1. • QA Automation Engineer @ Toptal • Blogs técnicos: stefanteixeira.com.br

    (pt-br) / stefanteixeira.com (en) • Co-organizador dos meetups DevOps Carioca e Grupo de Testes Carioca Contatos: • E-mail: [email protected] • Twitter: twitter.com/stefan_teixeira • LinkedIn: linkedin.com/in/stefanteixeira • GitHub: github.com/stefanteixeira • SlideShare: slideshare.net/stefanteixeira Sobre
  2. "Test coverage is a useful tool for finding untested parts

    of a codebase. Test coverage is of little use as a numeric statement of how good your tests are" (Martin Fowler, ThoughtWorks)
  3. "High coverage numbers are too easy to reach with low

    quality testing” (Martin Fowler, ThoughtWorks)
  4. "One sign you are testing too much is if your

    tests are slowing you down. If it seems like a simple change to code causes excessively long changes to tests, that's a sign that there's a problem with the tests." (Martin Fowler, ThoughtWorks)
  5. "The problem is that people optimize their performance according to

    how they’re measured. You can get 85% coverage by looking at the coverage conditions and picking the ones that seem easiest to satisfy…” (Brian Marick)
  6. Efeitos de métricas como meta • Mutirão de testes •

    Testes só para aumentar cobertura • Testes inúteis: getters, setters, construtores
  7. Meta levando a decisões ruins • Temos que testar a

    funcionalidade X • Testá-la pela API é muito simples
  8. Meta levando a decisões ruins • Temos que testar a

    funcionalidade X • Testá-la pela API é muito simples • Testá-la com unit tests é muito complexo
  9. Meta levando a decisões ruins • Temos que testar a

    funcionalidade X • Testá-la pela API é muito simples • Testá-la com unit tests é muito complexo E aí, como testar?
  10. Como saber se meus testes são bons? • Testes devem

    cobrir as partes mais complexas da aplicação
  11. Como saber se meus testes são bons? • Testes devem

    cobrir as partes mais complexas da aplicação • Testes devem efetivamente testar alguma coisa
  12. Conclusões • 100% de cobertura != bons testes • Teste

    as partes mais complexas da sua aplicação
  13. Conclusões • 100% de cobertura != bons testes • Teste

    as partes mais complexas da sua aplicação • Use testes de mutação para garantir que seus testes são eficazes
  14. Referências (parte 1) • Cobertura de código: • http://pt.slideshare.net/Kevlin/what-we-talk-about-when-we-talk-about- unit-testing

    (Palestra Kevlin Henney) • http://martinfowler.com/bliki/TestCoverage.html • http://martinfowler.com/bliki/AssertionFreeTesting.html • http://www.developertesting.com/archives/ month200705/20070504-000425.html (Conto sobre Code Coverage) • http://www.exampler.com/testing-com/writings/coverage.pdf (Artigo do Brian Marick sobre Code Coverage) • Complexidade de código: • http://blog.caelum.com.br/medindo-a-complexidade-do-seu-codigo/ • http://blog.caelum.com.br/como-medir-a-coesao-lcom/ • http://www.obomprogramador.com/2014/03/lack-of-cohesion-in- methods-4-lcom4.html • http://c2.com/cgi/wiki?AbcMetric
  15. Referências (parte 2) • Ferramentas: • http://www.sonarqube.org/ • https://github.com/es-analysis/plato •

    https://github.com/bbatsov/rubocop • https://codeclimate.com/ • Testes de Mutação: • http://pitest.org/ • https://github.com/mbj/mutant • http://visualmutator.github.io/web/ • https://www.npmjs.com/package/grunt-mutation-testing • https://pypi.python.org/pypi/MutPy/0.4.0 • http://pt.slideshare.net/labianchin/teste-de-mutao