También me parece que hay que intentar mantener que este porcentaje nunca baje de un límite (por ejemplo 80%).
Si se utiliza Scrum creo que es un elemento que hay que comprobar en las finalizaciones de todos los Sprints y tenerlo muy en cuenta en las retrospectivas para saber si vamos por buen camino o no.
También se puede llegar a indicarle a Maven que si el porcentaje de tests está por debajo de un limite ni siquiera llegue a compilarse el paquete y genere un error.
Recientemente nos hemos encontrado con un problema en el trabajo, y es que nuestra cobertura estaba bajando debido a unas clases que no pueden ser testeadas o en las que no se debería perder tiempo haciendo tests tontos:
- Entidades: ¿Realmente es necesario que todos los getter/setters de un bean se testeen si lo unico que hacen es devolver y settear un valor? ¿Acaso no confiamos en la generación automática de get/set del Eclipse? Yo personalmente no perdería el tiempo testeando estas clases.
- Stubs de Web services: Supongamos que tenemos unos stubs generados a partir de un WSDL. Me niego rotundamente a tener que testear estas clases.
Seguramente que habrá mil casos mas de clases que no es necesario testear y que mucha gente se planteará hacerlo para que la cobertura del proyecto no baje.
En vez de hacer malabarismos, hay una solución muy sencilla que es indicarle al plugin maven de cobertura que excluya las clases que queramos:
org.codehaus.mojo
cobertura-maven-plugin
com/company/models/*.class
clean
Con esta configuración le estamos indicando a cobertura que pase de todos mis modelos, que son los que tienen los get/set :-)