Sugiero escribir un conjunto completo de pruebas en áreas donde es sensato y práctico hacerlo. En áreas menos prácticas, escriba controles de cordura.
En mi experiencia, la sobrecarga de un conjunto completo de casos de prueba ciertamente vale la pena en la mayoría de los casos, pero de manera realista la cobertura del código tiene rendimientos decrecientes. En algún momento, escribir más pruebas solo para aumentar la cobertura del código simplemente no tiene sentido.
Por ejemplo, dependiendo de su idioma / tecnología, probar la interfaz de usuario puede no ser práctico o incluso factible. Muchas pruebas probablemente dependerán de lo que un usuario ve y no puede automatizarse. ¿Cómo probarías que un método para generar un captcha produce una imagen legible por un humano, por ejemplo?
Si un conjunto completo de pruebas le tomará tres días para escribir, la probabilidad de que se introduzca un error en ese componente en la pista es muy baja, y la función en sí solo toma media hora para escribir, probablemente debería pensar mucho sobre si ese tiempo vale la pena. ¿Quizás solo escribir un chequeo de cordura básico para esa función proporcionaría valor?
Mi consejo general sería que debe probar los componentes por completo donde las pruebas se pueden escribir con relativa facilidad. Sin embargo, si es un área que es muy difícil de probar, dibuje una línea en la arena y escriba pruebas que evalúen el área a un nivel más alto en lugar de probarla completamente.
En el ejemplo anterior de captcha, quizás escriba pruebas que verifiquen que se devuelve una imagen del tamaño y formato correctos y que no se arrojen excepciones. Eso le da cierto nivel de seguridad sin exagerar.