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 -~----------~----~----~----~------~----~------~--~---
