Supongamos que desea probar manualmente su aplicación cada vez que la implementa. ¿Cómo harías para hacer eso?
Bueno, para empezar, puede hacer una lista de todas las cosas que desea probar para no olvidarse de probar algo más adelante. Entonces, probablemente escribiría los pasos para cada prueba para asegurarse de que los hizo de la misma manera cada vez. Si no se aseguró de que el proceso de prueba que utilizó fuera consistente, sus resultados no serían consistentes.
Entonces, ahora que tiene la lista de pruebas que necesita realizar, debe abrir su navegador, leer los primeros pasos de la prueba, realizarlos y anotar el resultado. Repetiría este proceso para cada prueba en su lista.
La cantidad de pruebas que realiza continuará creciendo a medida que su aplicación crezca y a medida que encuentre nuevos errores. Por supuesto, estaría limitado a realizar estas pruebas a velocidad humana, lo que las haría bastante lentas.
La ironía aquí es que al recorrer mecánicamente una lista de operaciones, estás computando. Lo estás haciendo mucho más lentamente que, por ejemplo, una computadora.
Esta, entre muchas otras buenas razones, es la razón por la que escribimos pruebas unitarias: permiten que la computadora haga la computación para que no tenga que hacerlo.
Puedo ejecutar un conjunto completo de pruebas unitarias lo suficientemente rápido como para usarlo con frecuencia durante el desarrollo, no solo una vez por semana antes de la implementación. Esto me permite detectar errores más rápidamente, ahorrándome tiempo y dinero.
Incluso puedo escribir pruebas que predicen el comportamiento del sistema y luego escribir ese comportamiento (que ya sé que es correcto porque lo acabo de probar), un proceso conocido como Test Driven Development.