Una de las últimas maneras de protegernos de los bichos del futuro es no olvidar los bichos del pasado. Los antiguos bichos tienen una tendencia a volver a las bases de códigos de larga vida. Esto suele ser el resultado de que alguien no entienda por qué algo está escrito de una manera particular y lo elimine para «limpiarlo».
Esto presenta otro escenario en el que es útil tener otra forma de documentación ejecutable. Así, cuando un desarrollador desprevenido cambia algún código o quita algo, hay un código en ejecución para alertarlos de su error.
Típicamente la gente se encuentra con las pruebas de unidad en el contexto del desarrollo impulsado por pruebas. Este es un gran concepto, pero a menudo en la práctica, es un poco demasiado optimista y difícil de seguir (léase: el cliente quiere el código ahora). Sin embargo, esa discusión es para otra entrada del blog.
Lo que vamos a discutir en esta guía es cómo usar las pruebas de unidad para protegerte de futuros y pasados bichos. Piensa en esto como si de alguna manera invirtiera el concepto de pruebas TDD en algo un poco más pragmático con menos costos de tiempo por adelantado.
Te propongo que escribas pruebas DESPUÉS de que arregles un error. Vean esta discusión para ver más razones del porqué.
Esto sirve para algunos propósitos que podrían no ser inmediatamente obvios:
1. Mejora la documentación de la corrección de errores
Seguro que incluiste un bonito mensaje de confirmación indicando cómo arreglaste el error, pero no te detengas ahí. Es probable que a tu mensaje de confirmación y a tus comentarios les falte algo como:
- ¿Cómo probaste la solución?
- ¿Qué escenario exacto causó el bicho?
Aquí es donde entra en juego una buena prueba de unidad. Ya sabes cómo probar el micrófono. (Lo probaste antes de comprometerte, ¿verdad?) Así que codifica el escenario con el que probaste y deja que todos se beneficien de tu duro trabajo.
Las pruebas de la unidad son un excelente lugar para explicarlo todo y proporcionar documentación para la corrección de un error. No sólo puedes explicar cómo y por qué lo arreglaste, sino también cómo lo probaste. Esta información puede ser muy valiosa si el error vuelve a aparecer.
No lo olvides, una prueba de aprobación puede ser usada como una pista de dónde está el bicho no .
2. Código a prueba de futuro contra bichos duplicados
No es raro que un bicho en particular se cuele en un código base. Esto puede suceder debido a cambios en los requerimientos, errores de re-factorización, o cualquier número de situaciones. Puedes detectar las regresiones escribiendo una prueba de unidad para una corrección de errores específica y recordando ejecutar tus pruebas. Piensa en una prueba de unidad como si te dieran una tarjeta de salida de la cárcel por un error que podrías volver a inyectar más tarde.