Qual índice de cobertura de teste que a empresa de vocês exigem (se exigem) nos projetos que vocês fazem parte?
Geralmente entre 80% e 90%, considerando o que não dá para ser testado e
mesmo assim as feramentas de cobertura acusam que não tem teste.
Aqui usamos o SonarQube. Nao há uma exigência, mas é bom ter mais que 60%.
Temos um grande hábito de escrever testes unitário e de integração, mas mesmo assim não é tão fácil chegar a essa porcentagem. Depende muito também de como a ferramente está configurada.
Não sei se responde a pergunta mas eu estou começando a utilizar o TDD (Test-Driven-Development) nos meus projetos. Basicamente você escreve os teste antes de criar a logica das classes, isso ajuda a manter a simplicidade no código, coesão e baixo acoplamento, pode-se utilizar técnicas como Mock Object e Tell, Don’t Ask, entre outras junto ao TDD. É bem interessante, sugiro que você de uma pesquisada.
Eu pessoalmente acho uma métrica ruim quando isolada.
É importante vc saber a cobertura dos testes quando você executa uma suíte de testes. Agora precisa ser esperto pra analisar o resultado. Pode ser que numa dessas de chegar no mínimo da cobertura aceitável de, digamos, 90%, vc pode deixar de fora partes importantes do código.
Ou pode ser impossível chegar a x% pois nem sempre agrega valor.
Se a ordem de execução de um código não é previsível ou se tem integração com código de terceiros/nativo o bixo pega.
Pra projetos novos é bem interessante sim definir 80% ou 90% de cara. Porém um bom programador vai rodar os testes localmente e vai verificar a cobertura dos mesmos até pra melhorar os seus testes. Se a cobertura baixar e ninguém percebe até que o CI apita isso é um sintoma.
Combine metricas de % de codigo e linhas de código versus linhas de teste. E separe 3 tipos de classes de teste: sem mock, apenas com stubs e com mock.
Te garanto que abuso de mock é causa de bugs e isso está ligado ao design da aplicação. Existem patterns pra evitar isso.
Procurei ferramentas de metricas de codigo (estilo, complexidade, procurar por códigos duplicados). Às vezes vc pode criar policies tipo “não pode ter warnings”, “não pode ter catch vazio” etc. isso ajuda muito se combinado com coverage
1 curtida
Aqui tudo que for funcionalidade crítica deve ser coberto por testes funcionais automatizados, que no fundo é automatizar o que os QAs sempre fizeram 100% manual. Aqui não tem a necessidade de teste unitário, não atendemos programadores, não entregamos código isolado, entregamos requisitos funcionais. E também não tem a necessidade desenvolvimento TDD, o cliente acompanha se o que está sendo desenvolvido está ficando de acordo, então essa “garantia” é natural pois o cliente está dentro da mesma nave, não é fábrica. Enfim, não tem o problema para precisar da solução vendida pelo TDD. Então tudo vai depender do cenário que você estiver.
Onde trabalho não temos índice mínimo de cobertura, mas procuramos cobrir tudo em uma story (ou quase tudo) com testes. Aqui o dev escreve testes antes ou depois, não importa, mas pelamor, escreve testes.
Na maioria das vezes a story é entregue com dois tipos de testes: aceitação e unitários.
Quem programa test-driven dificilmente cai nas armadilhas do “ah, isso é complicado testar”, pois primeiro pensa em como testar, pra só depois implementar. Com test-driven o design do código vai fluindo naturalmente e quando se vê, cobre quase todos os cenários com unit e os principais (core) com acceptance. Sendo assim, o dev não precisa se preocupar com índice de cobertura, pq o mindset test-driven já garante que não (ou dificilmente) regride.
Já num projeto que não se aplica muito TDD, seria bom ter um índice pra não deixar o projeto virar um caos. Contudo, teste não é garantia de bug free, por isso saber aplicar test-driven com técnicas de padrões de projeto e clean code ajuda a amenizar.
Ah, aqui o “Business Analyst” (analista, funcional, PO, chame oq quiser) não precisa saber sobre índice de cobertura, ele apenas se preocupa que a feature atende os requisitos da story. E ponto. Detalhes técnicos e decisões sobre como escrever testes ficam a cargo do dev. Cabe ao dev ter a responsabilidade de fazer código que presta.
[EDIT] imo, o melhor índice de cobertura é a quantidade de bugs que aparecem em produção x a satisfação do cliente/usuário/interessado
Segue também um artigo do Martin Fowler sobre cobertura de código.
Você pode ficar até 2150 escrevendo testes, isso só vai aumentar a sua capacidade de detectar bugs.
Pra criar menos bugs, só aumentando a cobertura de profissionais capacitado s em linguagens funcionais. 