Mastery 13: Desarrollo guiado por pruebas

¿Sabías que existe una distinta para diseñar software? Alejándonos un poco de la metodología actual que hemos visto a lo largo de esta serie de artículos (Puedes revisar un resumen del proceso en mi último post Capítulo 10: Uniendo todo)

¡Así es! Hoy les vengo a platicar del desarrollo guiado por pruebas (Test Driven Development – TDD) pero comencemos, eso ¿cómo lo podemos definir?

TDD es una práctica de desarrollo de software que consiste en escribir primero las pruebas para el sistema y después escribir el código que será evaluado por las pruebas que escribiste primero. No te preocupes, puede ser algo confuso al principio pero espero que al final de este post todo tenga más sentido.

El principio fundamental del desarrollo guiado por pruebas es justamente escribir pruebas, generalmente pruebas unitarias que deben cubrir una función o tarea del sistema. Una vez que la prueba este elaborada, se deberá correr. Obviamente el compilador no tendrá idea de lo que está sucediendo porque no existe código de producción por ejecutar. Es ahí cuando comienza el desarrollo.

Las reglas del juego

Existen unas reglas muy importantes para seguir al pie de la letra la ideología del TDD, escritas por Robert C. Martin, coautor del manifiesto Ágil, las cuales dejo aquí:

No está permitido escribir ningún código de producción sin tener una prueba que falle.
No está permitido escribir más código de prueba que el necesario para fallar (no compilar es fallar).
No esta permitido escribir más código de producción que el necesario para pasar su prueba unitaria.

Las etapas del semáforo – Rojo, Verde, Refactor

Fase roja

En esta fase se debe escribir una prueba respecto al comportamiento del sistema que se desea implementar, por lo general partimos de un caso de uso o un requerimiento.

Recuerda, es muy importante escribir la prueba que use piezas de código como si éste ya estuviera escrito.

Fase verde

En esta fase toca escribir, ahora sí, todo el código necesario para pasar la prueba de manera exitosa. Pero, es importante enfocarte en resolver la prueba a cualquier costo, no tengas en cuenta los principios de buenas practicas para escribir código, para eso estará la fase de refactor, aquí la prioridad es pasar la prueba asignada.

Fase de refactor

En esta fase tienes permitido cambiar el código, limpiarlo, eliminar código duplicado, entre otras cosas. Aquí sí, es importante aplicar los principios de buenas practicas siempre y cuando el código siga pasando las pruebas en todo momento.

Test driven development — Fotografía extraída de: Paradigma Digital

En la imagen puedes ver el ciclo del semáforo aplicado, la primera fase equivale a la luz roja, al momento de escribir código de producción y pasar las pruebas se pasa a luz verde, y al fin, en la etapa de limpieza de código equivale a refactor.

¿Cómo escribir una prueba de manera efectiva?

Una buena prueba de software debe cumplir con algunos criterios o principios, estos son:

Legibilidad

Una prueba legible es aquella que tiene su propósito definido de manera clara, qué es lo que debe demostrar. Una muy buena práctica es nombrar a las pruebas de manera apropiada, de modo que el nombre refleje el comportamiento útil que el código debe cumplir.

Confiabilidad

Una prueba es confiable si falla o pasa de manera determinista, es decir, la variable de éxito siempre es la misma, no depende de factores externos como configuraciones, versiones, etc. Cualquier aspecto que no sea contemplado directamente en la prueba. Las pruebas deben ser unitarias y consistentes.

Mantenibilidad

Al igual que el código, las pruebas deben estar diseñadas de manera sólida, es decir, que no se rompa de manera sencilla. Recuerda seguir los principios de bajo acoplamiento y alta cohesión.

Ventajas del desarrollo guiado por pruebas

Existen bastantes pruebas de la efectividad del método TDD, y bien, si la implementación es correcta, la ventaja es bastante sencilla de distinguir:

TDD es la manera más sencilla de garantizar calidad de software y buen cubrimiento de pruebas, generando sistemas robustos y optimizados.

En sí la practica y dominación del desarrollo guiado por pruebas toma tiempo, la curva de aprendizaje quizá no termina de convencer a algunos de adoptar este ciclo para desarrollar software, sin embargo, una vez dominado por todo el equipo y con una buena mancuerna con el desarrollo ágil, TDD puede ser una herramienta que marque la diferencia en la calidad de los sistemas que se desarrollen, y por consecuente, mayor preferencia de los clientes hacía nosotros.

Al final, me gustaría dejarlos con un excelente video que me ayudó a comprender en unos cuantos minutos el concepto de TDD, espero les guste tanto como a mí.