El otro día se me ocurrió preguntar:
Y @jmbeas dijo que:
De lo que se puede deducir que si no tiene test el software no fue construido ágilmente. Y yo no estoy de acuerdo, pero 140 dan para lo que dan, así que intentaré explicarme un poco mejor aquí.
No es discutible que ante dos bases de código iguales es mejor la que tiene tests que la que no lo tiene.
Tampoco es discutible que uno de los principios del manifiesto ágil es:
La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.
Por lo tanto si el software no tiene tests no ha sido construido ágil mente por que se aleja de la excelencia técnica.
El problema surge a la hora de definir excelencia técnica. Yo estudiaba de pequeño una definición de calidad que siempre me gusto: «Una aplicación de calidad es aquella que satisface los requisitos del cliente». No necesariamente la mejor aplicación desde el punto de vista del puro diseño es una aplicación de calidad.
Y IMHO a veces los requisitos del cliente exigen velocidad, y creo que nadie discutirá que en muchos contextos, en mi caso en todos los proyectos en los que he estado, escribir tests tiene coste, a veces solo en dinero, pero muchas veces también en tiempo.
También el manifiesto hace hincapié en «working software» y una aplicación llena de tests que no hace nada, es muchas cosas, pero no hay «working software».
En alguna de las primeras conferencias Rails, algunos defensores del TDD, famosos muchos de ellos, me decían que yo estaba en el siglo XIX por pensar así, pero luego cuando montaron su propio proyecto el TDD quedó para los clientes.
Yo creo que los tests tienen valor, pero no siempre el valor supera al coste. Y os puedo asegurar que es muy difícil convencer a un cliente de que pague por algo que, sin duda tiene valor, pero el cliente no percibe. En ASPgems insistimos en dotar a las aplicaciones de tests, pro en el momento adecuado, no desde el principio del proyecto.
En NeuroK tenemos una buena cobertura de tests de la aplicación, y procuramos cuidarla y mantenerla, pero el nivel de cobertura cambia con el tiempo, y en los primeros meses de vida de la aplicación el nivel de cobertura era muy bajo.
Como decía un amigo:
En teoría las cosas son iguales en la teoría y en la práctica, pero en la práctica NO.
Totalmente de acuerdo Agustín! A mi me pasa lo mismo, al principio de los proyectos el time to market es importantisimo y por lo tanto alargar este tiempo para escribir tests que no son imprescindibles no es justificado. Y con el tiempo y la estabilidad del proyecto ya añadimos y completamos los tests que según pasa el tiempo las apps se vuelven más complejas y la importancia de los Test argumenta para garantizar el la estabilidad y la calidad del proyecto.
Hola Agustín, gracias por iniciar esta discusión.
Como en muchas de estas discusiones, el contexto importa. En mi caso no he trabajado nunca en un entorno «start-up», así que todo lo que voy a decir aplica desde mi experiencia en empresas más grandes y más estables.
Creo que la dicotomía escribir tests vs velocidad es un poco falsa. Si el equipo tiene los conocimientos para escribirlos, mi experiéncia es que se va más rápido escribiendo tests y, concretamente, haciendo TDD. Tanto en el corto plazo como, sobretodo, en el largo, dónde una base de código mal diseñada y sin tests hará ir mucho más lento el futuro desarrollo (como tu bien dices).
Hay gente capaz de crear diseños espectaculares sin TDD ni nada parecido y añadir tests después. Yo no lo soy y por eso es por lo que recomiendo TDD. Puede que vuestro caso sea diferente por la experiencia del equipo, la experiencia en los proyectos que hacéis, etc.
Yo por eso a mis clientes siempre les recomiendo (y hago cuando estoy trabajando con ellos) utilizar TDD desde el principio.
También es cierto que conozco casos de empresas que han tenido que crecer a lo bestia, que no tienen batería de tests, y que todo parece funcionar correctamente. Lo que no tengo tan claro es que si los hubieran hecho ahora no estarían dónde están. En eso tu tienes más experiencia y confío en tu criterio 🙂
Así que supongo que la respuesta buena es la gallega, o sea, un gran depende. Que también es la gracia de nuestra profesión, que si todo estuviera muy claro desde un buen principio sería muy aburrido.
Un abrazo!
Gracias, por tu comentario. Me quedo con el depende. En lo que discrepo es que haciendo TDD se haga más rápido. Sin duda el software es mejor (asumiendo que la definición de mejor es compartida), pero en mi experiencia se tarda más.