Estamos fazendo os testes unitários da camada de serviço aqui na empresa e ficamos em dúvida se é necessário testar métodos que apenas “repassam a chamada para o DAO”, nesse caso usando mock.
O nosso problema é por que chegou a nós um “número mágico” de cobertura de 85% e não estamos conseguindo atingir esse percentual sem testar códigos desse tipo.
Alguém já passou por esse problema qual a solução?
Algumas possíveis soluções que consigo enxergar são:
Criar esses testes, ao meu ver, inúteis
Descobrir alguma forma da ferramenta de cobertura ignorar esses métodos
Encontrar algum material que me dê algum embasamento para discutir sobre esse número de 85%
85% é um valor bem para um projeto já em andamento.
Começar com 30% e depois ir subindo seria uma excelente prática.
O Cobertura (caso seja ele que vocês estão a utilizar) tem configuração de qual classe testar ou não.
Geralmente essas ferramentas tem essa opção.
wcaquino
Hebert,
Nós já estamos aumentando a cobertura há algum tempo e temos como meta final 85%. O problema é que para chegar nesse percentual, temos que testar esses métodos. A nossa dúvida é se tem algum ganho em gastar tempo e esforço para testar esse tipo de método…
Estamos usando o Cobertura sim, e configuramos ele para avaliar apenas o pacote de Serviços no momento. O problema desse caso é que o método que gostaríamos que o cobertura desprezasse está em uma classe importante, que necessita da “atenção” do cobertura.
paulo1911
Ola amigo, aqui na empresa trabalhamos com essa meta de cobertura de no mínimo 80%.
Como usamos o maven, existe uma configuração que informamos quais os pacotes de classes serão excluidos, ou quais classes serao excluidas.
classes Abstratas, classes de constantes, Enums, configurações, properties, etc… fica de fora da cobertura.
Classes de modelo tb ficam de fora da cobertura.
No entanto, métodos que disparam exceptions tb são testados em todos os cenários.
A prática do TDD ajuda bastante a criar um design de classes que fique bem coeso e facilite tb os testes e criação de mocks.
fica a dica.
edu_fernandes
Na dúvida? Teste!
Por exemplo neste caso, teria a certeza de que o método devolve o valor esperado. Parto da premissa de que não existem testes inúteis.
Não testou? Então não implante. Esta é a regra. Teste, teste, e teste um pouco mais.
Hebert_Coelho
wcaquino:
Hebert,
Nós já estamos aumentando a cobertura há algum tempo e temos como meta final 85%. O problema é que para chegar nesse percentual, temos que testar esses métodos. A nossa dúvida é se tem algum ganho em gastar tempo e esforço para testar esse tipo de método…
Estamos usando o Cobertura sim, e configuramos ele para avaliar apenas o pacote de Serviços no momento. O problema desse caso é que o método que gostaríamos que o cobertura desprezasse está em uma classe importante, que necessita da “atenção” do cobertura.
Opa, que bom.
Realizar um teste e um método que chama outro seria bem simples e ajudaria aumentar a cobertura. Talvez não eficiente, fazer o que né? =/
Se o que eles querem são números, dê a eles os números uai. [=
renanreismartins
wcaquino se vc tem uma camada de “serviço” que apenas delega chamadas, pq soh nao chama o dao direto?
um ultimo detalhe, esse código seu não apenas delega chamadas, ele tem uma “logica” que trata uma exceção e lança outra. Entao eu testaria isso sim.
grande abrassss
wcaquino
Renan,
Nessa classe de serviço tem vários métodos com lógicas complexas, mas tem alguns métodos no estilo desse que eu exemplifiquei. Fizemos a cobertura de tudo que tinha lógica e deixamos apenas esses mais simples, só que não está atingindo a meta de 85%.
Realmente tem essa lógica que seria controlada no teste via mock, aí estávamos achando que esse cenário estaria testando mais o mock que a aplicação em si :lol:
Obrigado pelas contribuições, estou vendo que não tem por onde correr mesmo… testar, testar e testar
