Citar:
Claro, pero es que las pruebas unitarias son parte del proceso de desarrollo y es impensable usarlas en un sistema en producción. Lo que describes son tareas muy comunes para un administrador de sistemas o de BD.
Citar:
No es que yo sea un experto en testing, sólo que si te pones a medir el tiempo que generalmente se invierte en encontrar la causa de un error (durante el desarrollo) y en su corrección, te das cuenta que necesitas buscar una forma más eficiente de hacer las cosas. Por otra parte la única relación respecto del tamaño de la aplicación es probablemente la cantidad de casos de prueba, pero no es que en una aplicación pequeña no sea necesario hacer pruebas unitarias (puedes no hacerlas, pero seguramente el tiempo de desarrollo será mayor).
Correr pruebas automatizadas luego de un cambio o la introducción de una nueva característica te asegura que el sistema sigue funcionando para los casos de prueba que definiste o te permite encontrar más rápidamente los errores y su causa (según si el sistema pasa los casos de prueba o no).
Citar:
Claro, es lo que te decía. También yo he realizado pruebas de modo similar en mis desarrollos. Pero esto no son pruebas unitarias. Cuando las pruebas las haces de tal modo que puedes repetir su ejecución tantas veces como necesites y en el momento en que lo necesites (por ejemplo, puedes automatizarlas para que se ejecuten cada vez que se introduce una modificación -lo que requiere generalmente el uso de un sistema de control de versiones-), entonces el valor de la prueba aumenta en gran medida.