2009/11/22 Guillermo Schwarz <[email protected]> > ... > 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? > > Para ser profesionales en nuestro trabajo.
> 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 -~----------~----~----~----~------~----~------~--~---
