Dúvida: Testes unitários + Mock + Cobertura

Assuntos Gerais Agile
#1

Bom dia,

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.

Exemplo simples de um método:

public Entidade getById(Long id) {
    try {
        return entidadeDao.getById(id);
    } catch(QualquerCoisaException e) {
        throws new OutraCoisaException(e);
    }
}

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:

  1. Criar esses testes, ao meu ver, inúteis
  2. Descobrir alguma forma da ferramenta de cobertura ignorar esses métodos
  3. Encontrar algum material que me dê algum embasamento para discutir sobre esse número de 85%

Grato pela ajuda.

#2

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.

#3

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.

#4

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.

#5

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.

#6

[quote=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.[/quote]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. [=

#7

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

#8

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

#9