Pruebas de Unidad, Código Limpio

El Diseño Guiado por Pruebas (DGP) nos pide que primero creemos las pruebas de unidad antes que el código de producción.

Las Tres Leyes del Diseño Guiado por Pruebas:

1.- No debe crear código de producción hasta que haya creado una prueba de unidad que falle.

2.- No debe crear más de una prueba de unidad que baste como fallida y no compilar se considera un fallo.

3.- No debe crear más código de producción que el necesario para superar la prueba de fallo actual.

Pruebas Limpias

Realizar pruebas incorrectas es igual o peor que no tener prueba alguna.

Las pruebas deben cambiar de acuerdo a la evolución del código.

Al modificar el código de producción, las pruebas antiguas comienzan a fallar.

  • Cuanto menos limpias sean las pruebas, más difícil será cambiarlas.
  • Cuanto más enrevesado sea el código de pruebas, más posibilidades de que estés más tiempo entendiendo los test y modificandolos, que creando código nuevo.

El código de prueba es tan importante como el de producción. Debe ser tan limpio como el código de producción.

¿Cómo se Consigue una Prueba Limpia?

La legibilidad es igual o más importante en las pruebas de unidad que en el código de producción.

Para que una prueba sea legible tiene que cumplir las premisas de:

  • Claridad
  • Simplicidad
  • Densidad de Expresión

«Una prueba debe decir mucho con el menor número de expresiones posibles»

Las pruebas deberían probar un único concepto en cada test y que cada prueba sea independiente de cualquier otra.

Las Pruebas Mejoran el Código de Producción

Las pruebas de unidad hacen que el código de producción sea flexible y se pueda mantener y reutilizar.

¿Por qué?

Si tienes pruebas, no tendrás miedo a realizar cambios en el código. Sin ellas, tendrás miedo a realizar cambios por la posibilidad de añadir errores no detectados. Así podrás mejorar la arquitectura y el diseño sin miedo alguno.

5 Reglas para unas Pruebas Limpias (FIRST)

  • Rapidez –> Las pruebas deben ejecutarse rápidas para ejecutarlas con frecuencia.
  • Independencia –> Las pruebas no deben depender entre ellas. Un fallo en una provocaría fallo en la dependiente.
  • Repetición –> Las pruebas deben poder ejecutarse en cualquier entorno. Si  no, tendrá una excusa de su fallo.
  • Validación Automática –> Deben devolver un resultado booleano.
  • Puntualidad –> Deben crearse antes del código de producción que hace que acierten.