Gerald Weinberg "The Psychology of Computer Programming" tiene un montón de buenas historias sobre la prueba. Uno me gusta especialmente es en el capítulo 4" Programming as a Social Activity " 'Bill', pregunta un compañero de trabajo para revisar su código y se encuentra diecisiete errores en tan sólo trece declaraciones Las revisiones de código proporcionan ojos adicionales para ayudar a encontrar errores, cuantos más ojos utilices, más posibilidades tienes de encontrar errores sutiles. Como Linus dijo: "Teniendo suficientes ojos, todos los errores son superficiales", tus pruebas son básicamente ojos robóticos. quién revisará su código tantas veces como desee a cualquier hora del día o de la noche y le informará si todo sigue siendo kosher.
Cuántas pruebas son suficientes depende de si está desarrollando desde cero o manteniendo una sistema existente.
Al comenzar desde cero, no quiere pasar todo el tiempo escribiendo pruebas y termina fallando en la entrega porque el 10% de las características que pudo codificar se probaron exhaustivamente. Habrá cierta cantidad de priorización para hacer. Un ejemplo son los métodos privados. Como los métodos privados deben ser utilizados por el código visible de alguna forma (public/package/protected), se puede considerar que los métodos privados están cubiertos por las pruebas de los métodos más visibles. Aquí es donde debe incluir algunas pruebas de caja blanca si hay algunos comportamientos importantes u oscuros o casos extremos en el código privado.
Las pruebas deben ayudarlo a asegurarse de que 1) comprenda los requisitos, 2) respete las buenas prácticas de diseño al codificar la capacidad de prueba, y 3) sepa cuándo el código existente deja de funcionar. Si no puede describir una prueba para alguna función, estoy dispuesto a apostar que no comprende la función lo suficiente como para codificarla limpiamente. Usar el código de prueba unitaria te obliga a hacer cosas como pasar argumentos como cosas importantes como conexiones de bases de datos o fábricas de instancias en lugar de ceder a la tentación de dejar que la clase haga demasiado y convertirse en un objeto 'Dios'. Dejar que tu código sea tu canario significa que eres libre de escribir más código. Cuando falla una prueba anterior, significa una de dos cosas, ya sea que el código ya no cumpla con lo esperado o que los requisitos para la función hayan cambiado y la prueba simplemente necesite actualizarse para ajustarse a los nuevos requisitos.
Al trabajar con el código existente, debe poder mostrar que todos los escenarios conocidos están cubiertos para que cuando llegue la próxima solicitud de cambio o solución de error, pueda explorar el módulo que considere oportuno sin el persistente preocupación, "¿y si rompo algo?", que lleva a pasar más tiempo probando incluso las pequeñas correcciones, entonces fue necesario cambiar realmente el código.
Por lo tanto, no podemos ofrecerle un número de pruebas rápido pero debe buscar un nivel de cobertura que aumente la confianza en su capacidad para seguir realizando cambios o agregar características, de lo contrario probablemente haya alcanzado el punto de devoluciones disminuidas.
No puedo entender si tu intención fue escribir "Solía probar" en el tiempo pasado, o "Probé todo" en el tiempo presente. – ripper234
Lo siento por mi inglés. Quería decir "Lo pruebo todo" ", pero como Lars A. Brekken también dijo aquí, es muy importante dar prioridad. – Jonathan