«¿Cuál debería ser la cobertura de pruebas? La única respuesta razonable es 100%»
— Robert. C. Martin
TDD es una de esas prácticas que lleva ahí años, pero muchos años (por si tienes curiosidad por saber cuántos años lleva dando vueltas, te dejo este post que es bastante curioso: «Utilizamos la novedosa técnica de TDD»… ¿Cómo? ¿Novedosa? ¿Seguro?).
Hace unos días dejé en esa lista de reproducción, que he creado en mi canal de YouTube, y que llamé «vídeos de culto», un mítico vídeo de Kent Beck hablando de, entre otros, TDD y eXtreme Programming. Y hace unos días dejé en Twitter y Linkedin este vídeo de Robert C. Martin también hablando de TDD.
No hace falta que me ponga a ampliar el post con referencias sobre TDD, hay gran cantidad, ni que argumente su relación con la Agilidad (es obvia). Pero lo curioso es que llevando tantos años y con tan buenas referencias… apenas se use.
TDD, la práctica olvidada
Yo que me «paseo» por muchos sitios te puedo dar constancia de ello, eso, o que yo tengo muy mala suerte y me toca que donde voy se echan de menos muchas cosas, entre ellas, un TDD.
Hay n-mil excusas para no usar TDD, su recopilación daría para un post. La mayoría de las veces vienen de que no se entiende TDD, ni sus beneficios y se acaba viendo como un sobrecoste.
Scrum Masters… concienciar de ello, de lo bueno que tiene TDD (así evitamos que el Scrum Master esté en peligro de extinción).
Las 3 reglas del TDD
Luego también están los usos no del todo correctos de TDD, esos TDD que realmente… no son TDD.
Unos amigos, que se están empezando a meter en esto del TDD, me pidieron algún tipo de consejo, regla, para que guiase sus TDD. Y, obviamente, esas reglas ya estaban inventadas.
Habrá quizá muchas otras pero a mí me parece que las 3 reglas de Robert C. Martin son bastante buenas para saber cómo va ese TDD. Y son esas:
- No está permitido escribir código que va a producción (código de negocio) sin tener antes una prueba unitaria que falle.
- No está permitido escribir más código en la prueba unitaria del necesario para que ocurra el fallo.
- No está permitido escribir más código (del que va a producción) del necesario para superar la prueba unitaria.
Si sigues las anteriores reglas, harás primero, antes de nada, pruebas unitarias pequeñas y escribirás el código justo para superarla.
Hazte un dibujo con las anteriores y pégalo ahí en la pared, donde se vea, el Karma de la Agilidad te lo agradecerá.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
Excelente post y buenas referencias!!! Sería bueno que escribieras sobre las ventajas de TDD vs los «costos»