En mi opinión, lo mejor que puedes hacer es olvidarte del porcentaje de cobertura de código. Me explico.
Cuando lees el libro de Kent Beck, que es el autor que puso de moda las pruebas unitarias, y que viene a ser el manifiesto de programación extrema, te das cuenta que no habla en ningún momento de porcentajes de cobertura. El lo que dice es qué hay que escribir todas las pruebas que se te ocurran, de cosas que pueden fallar, obviamente. Y una vez que el código pasa todas esas pruebas y no eres capaz de encontrar ninguna prueba más tu código ya es correcto.
A la hora de probar nuestro código existe un grupo de herramientas que son las de cobertura de código que nos ayudan en nuestro trabajo. Estas herramientas, en el caso de Java, lo que hacen es poner la máquina virtual en un modo en el que la máquina va diciendo por que líneas de código va pasando cuando se ejecuta código. De tal forma que si nosotros ejecutamos nuestras pruebas unitarias con una herramienta de cobertura de código y vemos que hay una serie de líneas de código por las cuales no se ha pasado, eso nos proporciona una información muy valiosa. Puede ser por dos motivos o bien nuestro juego de ensayo no es tan completo como nosotros creíamos y se nos ha escapado alguna casuística o bien es lo que se llama código muerto, es decir en algún momento ese código tuvo alguna utilidad pero en este momento ya no la tiene y no se usa y se puede eliminar.
El problema viene cuando se confunde un medio con un fin es decir el fin de las pruebas unitarias es asegura que código es correcto la cobertura del código es un medio. Si nos obsesionamos con los porcentajes con un 70% o 60% u 80% de cobertura es cuando estamos equivocando el medio y el fin.
Obviamente si nuestra cobertura de código es baja es prácticamente imposible que nuestro juego de ensayos sea completo ya que hay muchas líneas por las cuales no pasamos. Pero también se puede dar el caso inverso, es decir que hayamos pasado por todas las líneas de código no quiere decir que las condiciones que hemos puesto en el JUnit sean las correctas o todas las necesarias. De hecho podríamos poner como única condición el siempre valido assertTrue(true) y nuestra cobertura de código sería alta.
Es por ello que, como decía al principio, no creo que haya que darle especial importancia al porcentaje de cobertura. Si es un buen indicador pero necesita de una persona que supervise porque él nivel es bajo o si un nivel alto realmente me está asegurando la calidad.