Hola Diego, TDD es una filosofía mucho más profunda que sólo hacer tests al código fuente. Se puede aplicar a los diseños de software y a cualquier actividad humana en que los resultados puedan fallar. Por ejemplo, si creas un diseño de una planta de energía solar, ¿cómo pruebo que el diseño funciona? La respuesta es simple: Creo un prototipo pequeño que muestra que funciona. Muchas de las prácticas de XP se basan en el mismo principio.
Y para complementar las ventajas que mencionaste, creo que faltaron las desventajas: 1. Falta de confianza de parte de aquellos que nunca lo han practicado (siempre existe un "caso" imaginario en que piensan que el TDD no aplica). 2. Por definición los clientes (incluyendo a los usuarios) no utilizan TDD (aunque puede que en sus áreas de expertise sí apliquen un concepto equivalente). Un médico no te pregunta si quieres que se lave las manos antes de operarte, ni tampoco le haría caso al director del hospital si le dice que no se lave las manos para ahorrar tiempo. De la misma manera, los profesionales del desarrollo de software no deberían preguntar si deben hacer tests. 3. Requiere de más esfuerzo intelectual usar TDD. 4. Los proyectos terminan antes, ya que gran parte del tiempo en los proyectos sin TDD se pierde en estabilizar código que no funciona integradamente (los típicos problemas de integración). Con TDD, necesariamente todo el código está probado, de modo que muchos menos problemas se presentan, ya que al momento de introducir un problema se disparan todas las alarmas. Esto tiene como consecuencia que los empleados cambian de trabajo con más regularidad que el resto, lo que no es necesariamente bueno para los empleados. En resumen, cuesta convencer de introducirlo, hay más esfuerzo intelectual una vez que se introduce y es el cliente el que recibe los beneficios en vez de los programadores. ¿Porqué deberíamos hacerlo? Saludos, Guillermo. 2009/11/22 Diego Gomez Deck <[email protected]> > > Hola gente, > > > El dom, 15-11-2009 a las 13:55 -0300, Norberto Manzanos escribió: > > Muy buena discusión. > > > Si, cierto... me parece una discusión muy interesante. > > > > Aporto algunas ideas, probablemente muy teñidas de subjetividad, pero > > que tal vez aún así sirvan para algo.a > > Bueno, yo también voy a tirar mis ideas... y el tema de la > "subjetividad" es justamente uno de los pilares de mis ideas con > respecto al TDD. > > Creo que la programación basada en testing tiene varios puntos fuertes: > > - Automatización de las tareas de testeo. Como se dijo por acá, la > computadora no se aburre con las tareas que si nos aburren a los > programadores... cuando más pueda hacer la computadora, mejor. Como un > subpunto de este punto, en los sistemas donde hay usuarios "reales", > suele ser muy productivo hacer una herramienta para que ellos mismos > sean quien escriban algunos de los casos de tests. Nadie mejor que el > usuario para saber que se espera de un sistema, y los tests modelan > justamente eso: Lo que se espera del sistema. > > - Documentación viva del sistema: Los tests son documentos que (si están > bien factorizados) prueban un caso de uso del modelo y, que además, está > viva. No es como la documentación entre "", o en archivos de texto > externos (con estos nunca podemos saber si están actualizados) sino que > podemos debugearlos, y aprender del sistema desde los casos de uso. De > hecho, una de las cosas que me parece que falta en los frameworks de > unittesting es la posibilidad de generar documentación "en papel" del > sistema desde los tests. Con los tests, la documentación en papel es una > duplicación y no debería existir. > > - Posibilidad de cambios grandes, tanto de diseño como de > implementación, con la seguridad que al menos no rompimos lo que ya > funciona. Esto permite demorar los cambios de diseño lo más posible... > cuando más tarde, mejor; ya que es cuando más sabremos del dominio. Con > un sistema bien testeado, se puede empezar siempre con modelos muy naive > y depurarlos según aprendamos... Cuando un sistema relativamente > complejo no tiene tests, no es fácil meterse en grandes cambios de > arquitectura. > > - "Subjetividad": Norberto habló del impacto en el sujeto (el > programador), y yo quiero hablar de otro caso de subjetividad. Cuando > uno desarrolla en TDD (es decir: escribe el test ANTES de que los > objetos resuelvan el problema), uno piensa antes COMO USAR el modelo > (porque hay que probarlo desde afuera), y no como implementarlo. Aunque > la implementación de esos objetos la hagamos nosotros mismos, primero > nos ponemos en la vereda de enfrente, en la vereda de un "usuario" del > modelo. Ese pequeño cambio, en mi experiencia, siempre produce > protocolos de uso de los objetos mucho más simples y, por supuesto, > mucho más fáciles de entender e implementar. En mi experiencia, los > diseños que se obtienen con TDD son mejores (es decir: más simples). > > > Bueno, estos son mis 2 centavos por hoy. > > Saludos, > > -- Diego > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
