Por qué los tests funcionan
Posted by Admin on 04/03/2007 17:44
El otro día le tuve que explicar a un cliente en qué consiste el TDD, en menos de un minuto.
Cuando le expliqué que los tests se escriben antes del código, se extrañó mucho y me preguntó cómo podía ser.
Le expliqué el típico caso de un modelo que tiene como atributos nombre y apellido y queremos tener una función nombre_completo, que concatena esos dos campos. Se puede escribir el test antes que esa función y comprobar que el nombre_completo proporciona el resultado correcto dado un nombre y un apellido conocido. Antes de escribir la función el test fallará, y luego funcionará. Es un ejemplo muy simple pero le bastó para enterarse al menos del concepto.
Ahora voy a contar una batalla del abuelo: durante mi paso por el proyecto del sistema de gestión de dominios, empezamos a hacer tests unitarios de alguna de la funcionalidad, no toda por desgracia. No era TDD, pero por lo menos había (algunos) tests.
Recuerdo un día que bajó una persona del Dpto. de Administración para decirnos que se había facturado incorrectamente un dominio de segundo nivel (.es, más caro) como uno de tercer nivel (.com.es, bastante más barato).
El dominio del error en cuestión tenía la forma xxxxcom.es e incorrectamente se había tratado como un dominio tipo .com.es, a pesar de que no era así.
Como había tests unitarios en el método que calculaba el nivel del dominio a partir de su nombre, inmediatamente añadí el test. Pongo el equivalente en Ruby, aunque el proyecto se programó con Java.
assert_equals 2, Dominio.obtener_nivel("terminadoencom.es")
Sorprendentemente el test no falló. El método Dominio.obtener_nivel estaba bien escrito. Lo que pasaba es que en esa comprobación en concreto no se estaba utilizando.
Resulta que en el punto concreto donde se produjo el fallo, el código comprobaba “a mano” la terminación del dominio mirando si terminaba en “com.es”.
Aquello nos sirvió para corregir aquel bug, y además buscar por todo el código si había algún sitio más donde se estuviera haciendo mal. El programador de turno se llevó una pequeña reprimenda, pero la cosa no llegó a mayores.
En este caso, el hecho de tener tests unitarios permitió rápidamente encontrar la causa del problema.
