La implantación de TDD en nuestra empresa

Que el desarrollo guiado por pruebas, o Test-Driven Development (TDD) es beneficioso para la calidad de nuestro software es algo innegable. Nos permite desarrollar sin basarnos en el depurador para verifica que nuestro software sigue cumpliendo con los requisitos, y facilita la tarea de refactorización del mismo, precisamente gracias a ello, posibilitando así que el código quede más limpio y optimizado. El uso de las pruebas unitarias o de desarrollador no involucra mayor problema pero, ¿cómo incorporamos el proceso de desarrollo guiado por pruebas a nuestro equipo o empresa?

Si nuestra empresa nunca ha realizado un desarrollo basado en pruebas, lo primero que deberemos hacer es formar a los miembros de nuestro equipo adecuadamente. En este sentido, el conocimiento de las herramientas disponibles para la creación y automatización de las pruebas será indispensable, por lo que habrá que enseñar a nuestro equipo cómo usar estas nuevas herramientas y descubrir qué características y metodologías encajan mejor en nuestro propio entorno de trabajo.

Desde el comienzo se hará necesario un seguimiento de la aceptación del proceso por parte del equipo, ya que será vital conocer cómo interiorizan la filosofía de TDD y en qué modo es puesta en práctica. Para conseguirlo, estableceremos pequeños objetivos fácilmente alcanzables, tal vez limitando el alcance de las pruebas a determinados elementos de las aplicaciones, permitiendo así que los programadores se familiaricen lo suficiente con la metodología de TDD antes de abarcar metas más ambiciosas. De esta forma, conseguiremos una mayor interiorización de la misma más rápidamente y, mediante estos pequeños logros, también conseguiremos que el equipo se sienta motivado ante el cambio, reduciendo así una posible resistencia al mismo ya que, como cualquier otro cambio, TDD requiere por parte de nuestro equipo un cambio en los comportamientos adquiridos y el desarrollo de nuevos hábitos, como puede ser el desarrollar código SÓLO cuando existe una prueba que validar. Conviene recordar que tan del equipo son los programadores como los analistas o jefes de proyecto, que deberán, en su totalidad, amoldarse a las nuevas condiciones de trabajo impuestas por la metodología de desarrollo que hemos decidido adoptar.

Una posible hoja de ruta para la adopción de TDD en nuestra empresa podría ser la siguiente:

1. Formar al equipo.


2. Estudiar los requerimientos y limitaciones de nuestra organización.


3. Identificar los parámetros que nos ayuden a comprobar en qué medida se va desarrollando la implantación de TDD.


4. Establecer pequeñas metas que puedan ser fácilmente alcanzables, para ir incrementando el alcance y dificultad de las mismas de forma progresiva. Por ejemplo, establecer en qué partes del código se establecerán los métodos de prueba, e ir ampliando su alcance.


5. Delimitar un lapso de tiempo en el que se evaluará la adopción de TDD.


6. Usar TDD, escribiendo las pruebas siempre antes que el código que deba superarlas.


7. Comprobar la validez de las pruebas, y la adecuación de las mismas a lo definido en TDD.


8. Realizar ajustes, en base a la evaluación anterior.


9. Continuar ampliando el ámbito de actuación de nuestro equipo, abarcando cada vez más código.


10. Proseguir con la investigación y adopción de las mejores prácticas de desarrollo, y las herramientas más óptimas. Esto implica un reciclaje continuo del equipo, lo que hace que se sienta motivado y proactivo.

Para saber más:

• Test-Driven Development, de Eclipse Process Framework.


• Anti-patrones TDD, de James Carr.


• Tag Test-Driven Development, de TestingReflections.com.

Actualización (8 de abril de 2008): El blog registra una nueva entrada el 3 de abril de 2008 sobre Cheat Sheets, en concreto recogiendo una "hoja de trucos" o guía de Test-Driven Development, disponible para su descarga en formato PDF.