Hola tocayo! Estoy de acuerdo en tus dos primeros puntos "Automatización del testeo" y "Documentación viva del sistema" (aunque no creo que esté tan viva). Respecto a la posibilidad de hacer cambios grandes no estoy tan de acuerdo, creo que son un lastre que hace sentir segura a alguna gente. Y en tu último argumento veo que hablás de escribir primero y programar después, en eso estamos de acuerdo, también sabemos que se obtienen diseños mejores pero el punto es que TDD no es la única ni la mejor forma de hacer eso. Coincido en que primero hay que escribir los objetos y luego las clases, en que hay que declarar primero las necesidades y luego resolverlas. De esto hablaba ese tipo del video que originó ese chat, eso es lo que entiendo que gusta y sorprende a la gente. Pero eso no es exclusivamentre TDD, hay gente que trabaja asi desde hace 20 años. TDD propone esas prácticas y eso es positivo, pero creo que en un balance no termina en sistemas mejor diseñados, sino lo contrario, los sistemas en donde se abusa de TDD suelen estar muy poco factorizados, con bajos niveles de abstracción y con muchas mas clases de las necesarias. Todo esto porque justamente los tests desalientan los cambios estructurales que mejorarían, en el largo plazo, el diseño. TDD es algo que yo uso pero que trato de no abusar porque le experiencia me ha mostrado algunos efectos adversos, de la sigla TDD creo que la letra que me molesta es la primera D. La conducción de un desarrollo no debe ser un framework o una técnica, sino la interacción con el sistema de la manera mas cercana posible.
Hasta pronto y me alegra saber de vos. Diego Coronel On 22 nov, 09:35, Diego Gomez Deck <[email protected]> wrote: > 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. > > 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 --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
