Realmente me gusta la respuesta de @ RevBingo porque sugiere que la lucha hacia el 100% puede hacer que limpies o elimines el código no utilizado. Lo que no he visto en las otras respuestas es una idea de cuándo necesita una alta cobertura y cuándo no. Intenté comenzar esto. Creo que agregar detalles a un cuadro como este sería una búsqueda más útil que encontrar un número de cobertura de prueba que fuera adecuado para todo el código.
100%
Para una API pública, como las Colecciones java.util, que no está acoplada a una Base de Datos y no devuelve HTML, creo que el 100% de cobertura es un objetivo inicial noble, incluso si se conforma con el 90-95% debido al tiempo u otro restricciones El aumento de la cobertura de la prueba después de completar la función obliga a un nivel de escrutinio más detallado que otros tipos de revisión de código. Si su API es popular, la gente la usará, la subclasificará, la deserializará, etc. de maneras que no puede esperar. ¡No quieres que su primera experiencia sea encontrar un error o supervisar el diseño!
90%
Para el código de infraestructura empresarial, que toma estructuras de datos y devuelve estructuras de datos, el 100% sigue siendo probablemente un buen objetivo inicial, pero si este código no es lo suficientemente público como para invitar a un mal uso, ¿quizás el 85% sigue siendo aceptable?
75%
Para el código que acepta y devuelve cadenas, creo que las pruebas unitarias son mucho más frágiles, pero aún pueden ser útiles en muchas situaciones.
50% o menos
Odio escribir pruebas para funciones que devuelven HTML porque es muy frágil. ¿Qué sucede si alguien cambia el CSS, el JavaScript o todo el blob de HTML e inglés que devuelve no tiene sentido para los usuarios finales humanos? Si puede encontrar una función que use mucha lógica de negocios para producir un poco de HTML, vale la pena probarlo. Pero puede que no valga la pena probar la situación inversa.
Cerca del 0%
Para algunos códigos, la definición de "correcto" es "tiene sentido para el usuario final". Hay pruebas no tradicionales que puede realizar con este código, como la verificación gramatical automática o la validación HTML de la salida. Incluso he configurado declaraciones grep para pequeñas inconsistencias de las que comúnmente somos víctimas en el trabajo, como decir "Iniciar sesión" cuando el resto del sistema lo llama "Iniciar sesión". Este hombre no es estrictamente una prueba unitaria, sino una forma útil de detectar problemas sin esperar resultados específicos.
Sin embargo, en última instancia, solo un humano puede juzgar qué es sensible para los humanos. Las pruebas unitarias no pueden ayudarte allí. A veces se necesitan varios humanos para juzgar eso con precisión.
Absoluto 0%
Esta es una categoría triste y me siento menos persona por escribirla. Pero en cualquier proyecto suficientemente grande hay agujeros de conejos que pueden succionar a la persona por semanas sin proporcionar ningún beneficio comercial.
Compré un libro porque decía que mostraba cómo burlarse automáticamente de los datos para probar Hibernate. Pero solo probó las consultas Hibernate HQL y SQL. Si tiene que hacer mucho HQL y SQL, realmente no está obteniendo la ventaja de Hibernate. Hay una forma de base de datos en memoria Hibernate, pero no he invertido el tiempo para descubrir cómo usarla de manera efectiva en las pruebas. Si tuviera eso en ejecución, me gustaría tener una cobertura de prueba alta (50% -100%) para cualquier lógica de negocios que calcule cosas navegando por un gráfico de objetos que hace que Hibernate ejecute algunas consultas. Mi capacidad para probar este código está cerca del 0% en este momento y eso es un problema. Así que mejoro la cobertura de pruebas en otras áreas del proyecto y trato de preferir funciones puras sobre las que acceden a la base de datos, en gran parte porque es más fácil escribir pruebas para esas funciones. Todavía,