Quizás a nivel cognitivo, ningún profesional que valga la pena acepte no escribir pruebas automatizadas.
Sin embargo, los criterios económicos lo sacarían del mercado, contrariamente a lo que uno podría presagiar a simple vista. En el caso de los medicos, tienen un monopolio sobre el servicio de salud, pero si ese monopolio no existiera, algunos se lavarían las manos y otros no. De hecho, antes de deacubrir los microbios, los medicos rara ve se lavaban la manos antes de operar. En otras palabras, el mercado no reauleve de por si todos los problemas. Enviado desde mi iPhone El 22-11-2009, a las 22:24, Abel Armoa <[email protected]> escribió: > Que tal Guillermo: > > Yo creo que hay muchísimos profesionales que hacen las cosas bien si > mplemente por el gusto de hacerlas y porque están convencidos de que > así es como deben trabajar. Y la remuneración económica no tiene > nada que ver con eso. > Personalmente creo que la excelencia de nuestro trabajo no debería d > epender de cuánto nos pagan por el. > > Por este motivo no creo que el interés de los agentes económicos pue > da influir en algo en que TDD se siga utilizando o sea olvidado. > > Saludos, > Abel Armoa > > 2009/11/22 Guillermo Schwarz <[email protected]> > Exacto. Deberíamos hacerlo para ser profesionales (cumplir con plazo > s y calidad). > > Sin embargo, como no están los incentivos económicos, los que sigan > esa ruta no verán beneficios... Todos los agentes económicos buscan > maximizar su ganancia, de modo que eventualmente se olvidará la prác > tica del TDD. > > De hecho, tengo entendido que existía en los 60's, cayó en el olvido > y volvió a resurgir a principio del 2000 gracias a XP. > > Saludos, > Guillermo. > > 2009/11/22 Gabriel Brunstein <[email protected]> > > > 2009/11/22 Guillermo Schwarz <[email protected]> > ... > > En resumen, cuesta convencer de introducirlo, hay más esfuerzo intel > ectual una vez que se introduce y es el cliente el que recibe los be > neficios 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, p > ero > > 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 fuert > es: > > - 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 e > stá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 > > > > > > > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
