Pocas veces he trabajado en empresas o proyectos que incluyen TDD o unit testing como obligatorios, como premisa antes de empezar el desarrollo. En general ha sucedido en lugares que buscan estandarizar su ingenieria, o en un lugar donde un arquitecto astronauta lo propuso y luego se desaparecio.
En si la premisa del unit testing, es seductor en ambientes que aplican programacion orientada a objetos, o programacion funcional, por los altos niveles de abstraccion.
Si se inicia con Test Driven Development, iniciar creando una prueba unitaria, que no sabes que parametros va a recibir, ni como se debe comportar, ni con que se va a integrar, puede parecer absurdo. A menos que se tenga un diseño detallado, en whitepapers los cuales en la mayoria de los casos, van a cambiar fuertemente en su implementacion.
Entonces llegamos a ese punto donde empezamos a escribir codigo que hace llamadas a funciones. Y a escribir funciones que devuelvan lo que necesitamos segun nuestro delirio. Terminamos todo el trabajo, pasamos a integrar.
Ahora todo lo que integramos, o no funciona como esperamos, o no nos gusta, o fue mal diseñado, ¿Y ahora?
Opcion 1: A escribir nuevas pruebas y nuevos diseños.
Opcion 2: A escribir lo que debe funcionar y luego adaptamos todas las pruebas.
Opcione 3: Vamos cambiando las pruebas cada vez que cambiamos las funciones, para demostrar que estan bien.
Normalmente para cumplir deadlines se toma la opcion 2 o 3, botando a la basura, el milesimo valor que tenia nuestro TDD y nuestras pruebas unitarias.
Esa ha sido mi experiencia, siempre la prueba unitaria, no tiene ningun valor al empezar el proyecto, pero …
¿Cuando si tienen valor las pruebas unitarias? Particularmente yo les he encontrado valor y he visto el valor en organizaciones, cuando los proyectos ya existentes.
¿Por que? Pues porque ya hay una base de codigo estable, ya hay un punto de comparacion, y las pruebas unitarias que se desarrollan encima, son valiosas para casos funcionamiento regular, casos extremos, y bugs.
- Tenemos un producto sin ningun tipo de pruebas.
- Queremos asegurarnos que cada nuevo cambio no lo rompa.
- Hacemos pruebas para todo, literalmente todo o al menos todo lo critico. – Una vez me recriminaron por hacer pruebas para una dependencia, porque ya ese proyecto las habia hecho, luego actualizaron la version, mi prueba se rompio, todos lo ignoraron y resulta y acontese que esa dependencia se habia dañado con la actualizacion, de nada empresa aleatoria de mi pasado-
- Esto ahora demuestra un estado Quo del build. Y de la aplicacion.
- Los nuevos desarrollos no deben tocar estas pruebas. Solo pueden agregar nuevas pruebas donde corresponda.
- Los bugs o fallas que se descubran pasan a ser nuevas pruebas, normalmente siempre casos extremos que se olvidaran.
Ahora el proyecto de software tiene una capa de soporte, que lo proteje de romperse sin necesidad.
Que de hecho es el proposito del TDD pero no tiene ningun valor cuando no hay producto.
Es un acercamiento mas practico, y como siempre mi poco humilde opinion