Mejores prácticas de prueba de unidad para un novato de prueba de unidad

En los últimos años, solo he escrito pequeños componentes para personas en proyectos más grandes o pequeñas herramientas. Nunca he escrito una prueba unitaria y siempre parece aprender a escribirlas y, de hecho, hacer una toma mucho más tiempo que simplemente activar el programa y probarlo de verdad.

Estoy a punto de comenzar un proyecto a gran escala que podría tardar unos meses en completarse y, aunque intentaré probar los elementos a medida que los escribo (como siempre), me pregunto si las pruebas unitarias podrían ahorrarme tiempo.

Me preguntaba si alguien podría dar buenos consejos:

1. ¿Debería estar buscando pruebas unitarias al inicio del proyecto y posiblemente adoptar un enfoque TDD?
2. ¿Debo escribir pruebas a medida que avanzo, después de completar cada sección?
3. ¿Debo completar el proyecto y luego escribir pruebas unitarias al final?

Algunos dirán lo contrario, pero sugeriría que separe las pruebas de unidad y TDD. TDD es un cambio mental y las pruebas unitarias parecen tomar inicialmente tiempo. Si considera que son un solo elemento, existe el riesgo de que no verá suficientes beneficios de inmediato y habrá una tentación de simplemente dejar caer TDD y pruebas de unidad con él.

Lo primero es escribir algunas pruebas unitarias. No tienen que ser perfectos al principio. Solo enséñese cómo probar pequeñas unidades de código y cómo usar la burla para aislar componentes.

Este es el que más tiempo toma, pero tiene, con mucho, el mayor beneficio. Una vez que note que ya no tiene que pasar por 14 páginas web para llegar a la que desea probar, sabrá de lo que estoy hablando.

Para mí, el gran momento de Eureka fue una aplicación de Windows en la que estaba tratando de probar una expresión regular que requería completar dos formularios antes de poder llegar a ella. Instalé NUnit y escribí una prueba sobre ese método y vi cuán rápido ahorré horas de tiempo de prueba. Luego agregué más pruebas para lidiar con los casos extremos. Y así.

Luego aprende a escribir pruebas unitarias bien. Aprenda el equilibrio entre las pruebas frágiles que son rápidas de escribir y escribir muchas pruebas individuales. Esto es bastante fácil La lección es que, idealmente, cada prueba solo prueba una cosa, pero aprende rápidamente cuánto tiempo lleva, por lo que comienza a inclinarse un poco sobre la regla hasta que escribe una prueba que rompe cada cambio de código, luego retrocede hacia el equilibrio correcto (que está más cerca del primero que del segundo).

TDD es, como dije, un cambio mental importante en su forma de trabajar. Sin embargo, no agregará mucho tiempo a su proceso de desarrollo una vez que ya esté escribiendo pruebas de todos modos. Y, lo prometo, verá que su estilo de codificación mejora ante sus propios ojos. O más bien, si no lo sueltas, no es para ti.

Una última cosa a tener en cuenta es que TDD no se limita a las pruebas unitarias. El diseño impulsado por la prueba de aceptación forma parte de TDD. Otra buena razón para no mezclarlos en tu mente.

Estoy de acuerdo con los demás (definitivamente no escriba sus pruebas al final, TDD toma tiempo para aprender, comience con las pruebas como pueda, apunte a TDD completo eventualmente). Pero quería agregar una cosa en respuesta a su comentario: "Me pregunto si las pruebas unitarias podrían ahorrarme tiempo".

Mi respuesta es un inequívoco sí. Aprendí el enfoque TDD hace aproximadamente 10 años, después de una cantidad similar de tiempo de codificación sin pruebas. En estos días, si estoy haciendo algo corto (<250 loc) y simple, o algo descartable, entonces no lo haré TDD. De lo contrario, sí, y precisamente porque ahorra tiempo.

El ahorro de tiempo se presenta de tres maneras: menos WTF, menos depuración y menos miedo. Lo primero es obvio: pasas mucho menos tiempo preguntándote qué demonios está haciendo lo que construiste. Cuando tiene un problema, la depuración es mucho más fácil, porque a) detecta errores probados al instante yb) los errores no probados tienen menos lugares para esconderse.

Sin embargo, cuanto menos miedo es, más sutil. Hasta que haya pasado un tiempo en una base de código TDD, ni siquiera se da cuenta de cuánto tiempo pasa preocupándose por los cambios que está haciendo. ¿Funciona X? ¿Romperá Y? ¿Hay alguna Z que pueda verse afectada? Con TDD, eso desaparece, porque convierte sus miedos en pruebas, y luego la computadora automatiza las preocupaciones. Un desarrollador más valiente es un desarrollador más rápido.

1. ¿Debería estar mirando la unidad al principio y adoptar un enfoque TDD?

2. ¿Debo escribir pruebas a medida que avanzo después de completar cada sección?

Cualquiera de estos, pero no la tercera opción .

Como señaló @pdr, aprender las pruebas unitarias adecuadas lleva tiempo. Definitivamente, desea tomarse su tiempo para aprender al comienzo del ciclo de vida del proyecto, no hacia el final cuando se acerca la fecha límite. De esta manera, ya estará al día, e incluso puede comenzar a cosechar los beneficios para cuando se acerque la fecha límite, debido a que detectó la mayoría de los errores al principio del ciclo de vida del proyecto.

Tenga en cuenta que la primera prueba unitaria siempre es la más difícil, especialmente si está probando código ya escrito. Es posible que dicho código no sea compatible con las pruebas unitarias, por lo que puede ser difícil conectar todos los objetos con el estado adecuado para la prueba. Por lo tanto, elija una prueba fácil, bastante aislada, de bajo nivel para sus primeros intentos de prueba de unidad, luego gradualmente puede aumentar el nivel de desafío. Una vez que tenga listo el primer dispositivo de prueba, el siguiente caso de prueba es mucho más fácil, y para cuando llegue al cuarto, estará produciendo casos de prueba como en una cinta transportadora. Ahí es cuando comienzas a sentir la bondad de poder probar de forma repetible y demostrable que tu código funciona ...

Personalmente prefiero el enfoque TDD y no creo que sea tan desafiante; requiere perseverancia, pero creo que cuanto antes comience con TDD, más pronto comenzará a ver los beneficios de las pruebas unitarias en general. Sin embargo, puede ser que las primeras pruebas unitarias sean mejores para escribir el código que ya tiene. Luego, una vez que lo domines, puedes comenzar a experimentar con TDD.

Creo que lo mejor para un novato es abordar algunos katas de código que se prestan a pruebas unitarias. Por ejemplo; validando una dirección de correo electrónico. TDD se convierte en el flujo natural una vez que haya abordado algunos de estos Code Katas. Consulte el siguiente código kata para el validador de dirección de correo electrónico que mencioné: Validador de correo electrónico

Para obtener una explicación de qué Código Katas son para aquellos de ustedes que no saben, consulte el siguiente enlace: Código Katas