Digamos que quería probar su aplicación manualmente cada vez que la implementó. ¿Cómo harías para hacer eso?
Para empezar, puedes hacer una lista de todas las cosas que quieres probar para que no te olvides de probar algo más adelante. Entonces probablemente escribirías los pasos para cada prueba para asegurarte de que los hiciste 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, abriría su navegador, leería los pasos de la primera prueba, los realizaría y anotaría el resultado. Repetiría este proceso para cada prueba en su lista.
La cantidad de pruebas que realice seguirá 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, haciéndolas bastante lentas.
La ironía aquí es que al repasar mecánicamente una lista de operaciones, estás calculando. Lo estás haciendo mucho más lentamente que, digamos, una computadora lo haría.
Esto, entre muchas otras buenas razones, es la razón por la que escribimos pruebas unitarias: dejan que la computadora haga la informática para que usted no tenga que hacerlo.
Puedo ejecutar un conjunto completo de pruebas de unidades lo suficientemente rápido para usarlo con frecuencia durante el desarrollo, no solo una vez a la 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 esa conducta (que ya sé que es correcta porque acabo de probarlo), un proceso conocido como Test Driven Development.