¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.¿Buscas nuestro logo?
Aquí te dejamos una copia, pero si necesitas más opciones o quieres conocer más, visita nuestra área de marca.
Conoce nuestra marca.dev
Jose Ignacio Herranz 17/01/2011 - Actualizado: 13/04/2023 Cargando comentarios…
TDD o Test-Driven Development (desarrollo dirigido por tests) es una práctica de programación que consiste en escribir primero las pruebas (generalmente unitarias), después escribir el código fuente que pase la prueba satisfactoriamente y, por último, refactorizar el código escrito.
Con esta práctica se consigue, entre otras cosas, un código más robusto, más seguro, más mantenible y una mayor rapidez en el desarrollo.
En este post voy a centrarme solamente en cómo TDD afecta al diseño de software, si queréis más información, hay una introducción bastante buena en la Wikipedia y Carlos Blé tiene disponible online un libro muy completo. Además, en esta infografía os contamos en qué consiste TDD, en qué principios se basa (SOLID) y cuáles son sus ventajas y desventajas. Y, si quieres profundizar aún más, te recomendamos que le eches un vistazo a TDD, una metodología para gobernarlos a todos y Molecule: desarrollo TDD en Ansible.
Antes pensaba que TDD era una forma de programar que consistía en generar primero los tests unitarios antes que la propia aplicación, con lo que conseguías desarrollos de más calidad a costa de disminuir la productividad. Creo que es la misma idea que tiene la mayoría de la gente que conoce por encima esta práctica, pero que no se anima a utilizarla.
Sin embargo, últimamente he estado profundizando un poco en TDD y me he dado cuenta de que esto no es cierto, TDD no es para hacer pruebas, es una práctica que envuelve el desarrollo en su conjunto, especialmente el diseño de software.
De hecho, algunos dicen que su última letra, debería significar diseño y no desarrollo. Es decir, diseño orientado por las pruebas.
TDD fue creado por Kent Beck (quien también inventó Extreme Programming y JUnit), y en esencia, es un proceso a seguir, lo cual ya lo hace diferente a un simple enfoque de pruebas primero:
Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor.
Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.
TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.
El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:
Vamos con un ejemplo práctico de este ciclo:
public void testSuma() { assertEquals(8, Calculadora.suma(3,5)); }
Este punto es para mí el más importante del TDD y que supone un cambio de mentalidad, primero escribo cómo debe funcionar mi programa y después, una vez lo tengo claro, paso a codificarlo.
Al escribir el test estoy diseñando cómo va a funcionar el software, pienso que para cubrir la prueba voy a necesitar una clase Calculadora con una función que se llame Suma y que tenga dos parámetros.
Esta clase todavía no existe, pero cuando la cree, ya sé cómo va a funcionar. Este caso es muy trivial, pero muchas veces no sabemos exactamente qué clases hacer o qué métodos ponerle exactamente.
Es más, a menudo perdemos el tiempo haciendo métodos y clases que pensamos que luego serán útiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD sólo hacemos lo que realmente necesitamos en ese momento.
public class Calculadora { public static int suma (int a, int b) { int c = a + b; return c; } }
public class Calculadora { public static int suma (int a, int b) { return a+b; } }
En ejemplos más complejo, según vayamos escribiendo más test, deberíamos buscar código duplicado y agruparlo en funciones o utilizar la herencia o el polimorfismo.
Esta forma de trabajar es también muy buena para entender el código. Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión.
Una buena forma de practicar TDD es a través de katas, de las que podéis ver un ejemplo de resolución de la kata Mars Rover en este post.
En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.
También hay que decir que no todo es perfecto en TDD, cuando llegue el momento de crear un test sobre la interfaz de la calculadora la cosa se complica. Los puntos flojos que veo en TDD son:
Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.
Cuéntanos qué te parece.