Por un lado, casi nunca me siento y escribo pruebas unitarias. Las pruebas unitarias son un medio para un fin, no un fin en sí mismas. Son una forma de responder "¿este código hace la tarea básica que se supone que debe hacer?"
Por ejemplo, algunas personas escribirán una función y luego abrirán una sesión interactiva para probarla con algunos valores y asegurarse de que funciona:
def fact x
if x == 0
1
else
x * fact(x-1)
end
end
>> fact 10
=> 3628800
>> fact 7
=> 5040
Pero ahora descubres un error:
>> fact -1
SystemStackError: stack level too deep
from (irb):2:in `fact'
from (irb):5:in `fact'
from (irb):10
Entonces lo arreglas:
def fact x
if x < 0
raise "Can't take the factorial of a negative number"
elsif x == 0
1
else
x * fact(x-1)
end
end
>> fact -1
RuntimeError: Can't take the factorial of a negative number
from (irb):3:in `fact'
from (irb):10
Pero ahora realmente debería probar para asegurarse de que todavía funciona:
>> fact 10
=> 3628800
>> fact 7
=> 5040
Como puede ver, sigue repitiendo las mismas pruebas ... y tiene que comparar los resultados visualmente. Las pruebas unitarias son una forma de evitar la repetición en este caso; Reduce la cantidad de trabajo que necesita hacer. Y si bien este es un pequeño ejemplo tonto, en el mundo real, se vuelve cada vez más importante y cada vez más difícil de probar manualmente. Lo que esto significa, por supuesto, es que la gente simplemente no prueba los componentes individuales; solo prueban todo el programa. Pero luego surgen errores, y son mucho más difíciles de encontrar. O ocurren errores, y se corrigen, pero alguien introduce el mismo error de nuevo, porque nadie agregó un caso de prueba para asegurarse de que no sucedió. O alguien mira un gran fragmento de código y dice: "No tengo idea de lo que se supone que debe hacer, ya que no está documentado y no tiene pruebas ... si soluciono este error, no tengo idea si romperé algo más dependiendo de ello; tal vez solo reescriba esto desde cero ".
Las pruebas unitarias reducen todo el trabajo extra en estos casos. La mejor manera de hacerlos divertidos es asegurarse de que las personas entiendan todo el trabajo que están reemplazando, y la flexibilidad adicional que viene de saber qué se supone que debe hacer cada parte del código. Hasta cierto punto, las personas necesitan tener un poco más de experiencia con la escritura y el mantenimiento de una gran base de código para comprender la importancia de las pruebas unitarias; Si todo su código es algo que escriben una vez y tiran, nunca lo entenderán.
Y las pruebas unitarias no deben escribirse después del hecho, como una tarea adicional una vez que tiene un código que "sabe" que ya funciona. Las pruebas unitarias deben escribirse primero, o al menos (ya que a veces olvida escribirlas primero) justo después de escribir el código en cuestión. Esto se llama desarrollo basado en pruebas y puede ayudar a mejorar sus API; si escribe las pruebas que ejercitan las API primero, aprenderá dónde es difícil usar las API incluso antes de escribir el código, y puede rediseñar mucho más fácilmente que si solo agrega las pruebas después.
MbUnitbiblioteca ha cambiado mi vida. La prueba automática es importante. Las pruebas automáticas ahorran tiempo. Las pruebas automáticas ahorran dinero. Las pruebas automáticas pueden salvar vidas. La prueba automática es la única forma. La prueba automática es otra red de seguridad. Cuando soy una de las 50 personas que trabajan en una gran arquitectura, me siento como otro ladrillo en una pared. Con las pruebas unitarias tengo el control.