45 minutos no alcanzan para mostrar tdd en serio y tampoco alcanza una tarde, es un cambio de hábito muy fuerte y se logra de a poco, pero yo no tengo problema el sabado por la tarde estemos toda la tarde haciendo un sistema con tdd, algo groso, no un ejemplito pedorro.
2009/11/13 Mariano Abel Coca <[email protected]> > Por lo que estuve leyendo, creo que el mayor problema con el que se han > encontrado es que los tests que han definido no son funcionales sino > estructurales. > > Los tests funcionales no debería ser necesario modificarlos o corregirlos > salvo que cambie la funcionalidad del sistema. Es decir, debería poder hacer > un refactoring sin tener que corregir ningún test. En esta situación, los > tests ayudan al refactoring, y aseguran que el sistema sigue andando una vez > de que cambiaste lo que querías, y está bueno. Hablo de tests que no testeen > el protocolo de creación y accessing de un objeto, sino que testeen que se > pueda hacer x o y en el sistema. > > Es por eso que me parece que es positivo que todos los programadores > conozcan el dominio de lo que están modelando, les da la posibilidad de > escribir esos tests funcionales automatizados. Lo bueno de estos tests es > que liberan la carga de los testers de tener que hacer un test de regresión > de semanas para garantizar que un refactoring no rompe nada. Cuando hago un > refactoring groso corro 23.000 tests que garantizan que el sistema funciona, > en menos de una hora. > > Hernán, me parece que es una buena idea la de armar un workshop de TDD, con > un ejemplo sencillo y que se pueda desarrollar, al menos parcialmente, en la > duración de una charla. No para esta Smalltalks que ya está bastante > cerrada, pero si tenés tiempo para el año que viene, creo que estaría bueno > y más de uno se anotaría para verla. Habría que pensar bien el ejemplo para > que no sea ni demasiado complejo ni demasiado pavo, que aporte lo que se > busca y que se pueda hacer en el tiempo acotado. > > Incluso puede ser la excusa para que encuentres el ejemplo ideal para tu > clase de poo :) ¿Viste que buenos que somos para buscarte laburo? > > Saludos, > > Mariano. > > > 2009/11/13 Guillermo Sapaya <[email protected]> > >> >> Hola a todos, >> >> Hernán decía: >> > no entiendo la pregunta... a ver, si queres tener software robusto >> tenemos >> > que testear, creo que eso no tiene sentido discutirlo. >> >> Seguro, hasta acá venimos pensando igual :-) >> >> Luego decía: >> >> > no entiendo la pregunta... a ver, si queres tener software robusto >> tenemos >> > que testear, creo que eso no tiene sentido discutirlo. >> > La pregunta es, cuando queremos testear y como. Al principio o al final >> del >> > desarrollo? de manera automática o manual? >> > Para mi: cuanto antes mejor y de manera automática. >> >> Para mí también, pero igualmente no concuerdo en que la mejor forma de >> testear sea haciendo TDD. Por lo menos no en mi caso y el de la otra gente >> que conozco. >> IMHO TDD es muy bueno y productivo para cierto tipo de gente y para otro, >> muy "deprimente". >> En mi caso me siento completamente atado de pies y manos y no me deja >> trabajar explorando el dominio como vos decís pero a mi manera. Siempre me >> caractericé por hacer sistemas prototipando, generando mis primeros >> objetitos y haciéndolos funcionar en conjunto para que estén disponibles lo >> antes posible para el usuario final. Y al contrario de lo que argumentan los >> pro TDD, querer prototipar o explorar el domino a partir de los tests me >> saca de foco mal. Creo que tiene mucho que ver con la forma de laburar de >> cada uno. >> En mi caso (y el de muchos compañeros smalltalkers) priorizamos el laburo >> rápido, evolutivo e incremental y el refactorizar SIEMPRE que se crea >> necesario sin importar lo grande que sea el impacto del refactoring siempre >> que sea para bien. Hacer eso con [ponga aquí el numero que desee] tests de >> fondo que después tengo que estar manteniendo para mí es impracticable. >> Repito, para mí. Seguramente en otros casos (como en el tuyo) les resulta >> satisfactorio. >> Al contrario de lo que he oído muchas veces, opino que el test del >> producto final NO es responsabilidad del desarrollador (seguramente acá es >> donde empiezan a dudar de mi buen desempeño como desarrollador y como lider >> de un grupo de desarrolladores :-P). >> El desarrollador debe asegurar que lo que hizo y entregó al integrador >> anda según lo pedido pero no debe hacer tests funcionales. Para ello hay >> otro rol que es el de testers, y un tester no tiene porque saber nada de >> Smalltalk, ni mucho menos de SUnit y TDD. Pero sí de la manera de trabajar y >> la sinergia del grupo de trabajo. >> El grupo de desarrollo debería brindarle a los testers una herramienta que >> permita poder trabajar en la realización de tests automáticos desde un >> principio. Me refiero a que el tester/usuario pueda definir todos los casos >> de uso que se le ocurra mediante el uso de dicha herramienta, y que estos >> casos de uso puedan "correrse" en cada nuevo release interno de desarrollo o >> cuando se desee. >> En fin, es un tema para largo pero bueno, por lo menos expuse mi opinión. >> >> Saludos, >> Guillermo Sapaya >> >> ----- Original Message ----- >> From: Hernan Wilkinson >> [mailto:[email protected]] >> To: [email protected] >> Sent: >> Fri, 13 Nov 2009 09:37:06 -0200 >> Subject: [clubSmalltalk] Re: DIscusion >> polemica >> >> >> > 2009/11/12 GallegO <[email protected]> >> > >> > > >> > > Hola Diego: >> > > >> > > Esto derivó en algo muy copado. El tema de los tests, creo que lo >> > > describiste perfecto, yo también siento lo mismo. El tema es que a >> > > medida que el desarrollo va madurando empieza a cambiar menos, hasta >> > > que se lo pone a prueba en distintas situaciones. En ese momento, >> > > puede ser que haya pasado bastante tiempo desde que se escribió ese >> > > código, empieza a surgir la necesidad de cambio real, dada por algo >> > > externo. Vamos a modificar y empezamos a dejar caconas por todos >> > > lados, sin darnos cuenta. No me quiero imaginar que pasa cuando ese >> > > mismo código lo toca alguien que no tiene el conocimiento de haberlo >> > > desarrollado, por más que sea una pieza única y bien pulida. >> > > ¿Como se hace para tener tantos tests? >> > > >> > >> > no entiendo la pregunta... a ver, si queres tener software robusto >> tenemos >> > que testear, creo que eso no tiene sentido discutirlo. >> > La pregunta es, cuando queremos testear y como. Al principio o al final >> del >> > desarrollo? de manera automática o manual? >> > Para mi: cuanto antes mejor y de manera automática. >> > >> > >> > > ¿Cuando desarrollas el producto si es que tenes que escribir tantos >> > tests? >> > > >> > >> > es un pregunta capciosa... lo escribis mienstras desarrollas... tambien >> > podríamos decir, si hay que diseñar tanto o jugar tanto en el workspace, >> > cuando desarrollas? pero la verdad es que si haces tdd bien, desarrollar >> > mientras hacer funcionar los tests, directamente desde el debugger, es >> > maravilloso >> > >> > >> > > Es decir, las respuestas seguramente sean simples, pero las ecuaciones >> > > en tiempo y dinero no. >> > > >> > >> > Eso es contextual y depende del tiempo... a mediano plazo cualquier >> sistema >> > no testeado te va a traer más problemas que uno testeado. >> > >> > >> > > >> > > Para mi, y para mi trabajo actual, no es tan simple. >> > > >> > > Saludos >> > > GallegO >> > > >> > > >> > > El día 12 de noviembre de 2009 18:58, [email protected] >> > > <[email protected]> escribió: >> > > > >> > > > Gabriel, >> > > > Antes que nada aclaro que tanto el tipado como el uso de tests son >> > > > técnicas que considero útiles en su debido contexto. Incluso creo >> que >> > > > los smalltalkers deberían tipar un poquito mas, o un poquito antes. >> > > > De los tests me preocupan dos aspectos: >> > > > 1) Un conjunto de tests es un sistema en si mismo y tiende a estar >> > > > fuertemente acoplado con el sistema que se quiere testear. Este >> > > > acoplamiento, como casi todo acoplamiento, resulta un lastre en la >> > > > evolución del sistema. Un sistema repleto de tests requiere mas >> tiempo >> > > > para ser modificado. Los amantes de TDD argumentan que dicha >> evolución >> > > > es "mas segura" porque está controlada por la validez de los tests, >> y >> > > > a mi eso me genera serias dudas. Otro efecto similar que producen >> los >> > > > tests es que el desarrollador (o jefe) se contenta con ver todas las >> > > > luces verdes y puede que se relaje en actividades de factorización, >> en >> > > > cambiar cosas, porque generalmente antes de fallar un tests, falla >> la >> > > > implementación del mismo. >> > > > 2) El segundo aspecto tiene que ver con el análisis y diseño. Está >> > > > bueno ver que los programadores de Ruby, a partir de TDD, entienden >> > > > que es bueno declarar primero la intención inicial y luego teclear >> la >> > > > solución. En Smalltalk esto se puede hacer con tests o con un >> > > > workspace. Esto implica haber entendido que era mejor escribir el >> > > > problema y luego la solución, a que ir directamente con un diseño y >> > > > luego ver si anda. Pero pensar que uno conoce el problema de >> antemano >> > > > suele ser ingenuo también, por lo tanto es mas conveniente ir >> > > > modificando también la intención inicial a partir de lo que se >> aprende >> > > > en la interacción con el sistema. Entonces ahi me molestan los tests >> y >> > > > prefiero usar workspaces, de esos que uso toco y tiro todo el >> tiempo. >> > > > Porque no solo no está claro una solución antes de resolver un >> > > > problema, sino que suele no estar claro el problema tampoco. >> Smalltalk >> > > > nos da muchas herramientas para entender un problema y en ese ida y >> > > > vuelta los tests estorban mas que ayudar. >> > > > >> > > > Saludos, >> > > > Diego Coronel >> > > > >> > > > >> > > > On 12 nov, 12:52, Gabriel Brunstein <[email protected]> wrote: >> > > >> Diego, me interesa tu punto de vista, por qué afirmas que es nociva >> la >> > > >> seguridad que te dan los tests? >> > > >> >> > > >> 2009/11/12 [email protected] <[email protected]> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> > Mariano, >> > > >> > Lo que decis me hizo relacionar el tipo de seguridad que da el >> tipado >> > > >> > con el tipo de seguridad que dan los tests. En ambos casos, IMHO, >> > > >> > sobredimensionada y nociva a corto plazo. >> > > >> >> > > >> > Diego >> > > >> >> > > >> > On 12 nov, 11:53, Mariano Abel Coca <[email protected]> >> > > wrote: >> > > >> > > Simplemente para aportar un detalle más. >> > > >> >> > > >> > > Saludos, >> > > >> >> > > >> > > Mariano. >> > > >> >> > > >> > > 2009/11/12 Hernán Galante <[email protected]> >> > > >> >> > > >> > > > Lindo intercambio :-) >> > > >> > > > A mi parecer, no tiene tanto que ver la escritura en sí, >> porque >> > > Ruby o >> > > >> > > > Objective C son una copia casi del "Smalltalk lenguaje". Lo >> que >> > en >> > > mi >> > > >> > > > opinión sucede es un mix de cosas. La primera, es el tipado. >> La >> > > >> > compilación >> > > >> > > > da cierta "seguridad", pues para el que escribe existe >> alguien >> > que >> > > se >> > > >> > las >> > > >> > > > sabe todas que te corrige (compilación para hacer el >> runtime). >> > > Esta >> > > >> > > > "seguridad" no se brinda en Smalltalk, pero todos sabemos que >> los >> > > >> > > > errores también se compilan sin problemas, el punto aquí es >> que >> > es >> > > un >> > > >> > engaño >> > > >> > > > emocional que hace sentir más seguro a sus programadores. >> > > >> >> > > >> > > Esta seguridad en smalltalk la obtenés fácilmente con una buena >> > > batería >> > > >> > de >> > > >> > > tests, e inclusive la seguridad que dan los tests es mayor que >> la >> > > que da >> > > >> > el >> > > >> > > compilador... Y no hablo sólo de tests funcionales sino de >> tests >> > del >> > > >> > > metamodelo. Claro que esas cosas en los otros lenguajes no >> existen >> > > :) >> > > >> >> > > >> > > > La segunda que no entienden de Smalltalk es su concepto >> > holístico. >> > > Que >> > > >> > no >> > > >> > > > hay diferencia entre el sistema en desarrollo y el >> productivo, >> > que >> > > no >> > > >> > hay >> > > >> > > > diferencia entre IDE y sistema en construcción, no hay >> > diferencia >> > > entre >> > > >> > mi >> > > >> > > > código y el código que ya existe, etc, etc. Cuantas veces han >> > > vistos o >> > > >> > nos >> > > >> > > > ha pasado cuando recién arrancábamos que nos poníamos en duda >> > al >> > > >> > modificar >> > > >> > > > un método de una clase de base, o no entender que podemos >> > > modificar el >> > > >> > IDE >> > > >> > > > para que browser haga las cosas que yo quiero, que puedo >> agregar >> > > en >> > > >> > cuestión >> > > >> > > > de unos minutos nuevas opciones, etc. >> > > >> > > > El otro punto, que tiene que ver con esto de un todo dentro >> de >> > > >> > Smalltalk, >> > > >> > > > es la no existencia de archivos. Esto genera cierta >> incomodidad >> > > para >> > > >> > > > programadores acostumbrados a que la unidad mínima sea un >> > archivo, >> > > pues >> > > >> > es >> > > >> > > > un esquema brindado fuertemente por el sistema operativo. El >> > hecho >> > > >> > también >> > > >> > > > es educacional, pues el ambiente cuantas veces se "ensucia" o >> > > >> > "contamina" y >> > > >> > > > empezamos a no saber para que lado ir. Eso en un ambiente >> basado >> > > en >> > > >> > > > archivos, solo se disfraza la suciedad .. :-). Es más, el >> hecho >> > de >> > > >> > cambiar >> > > >> > > > de una BBDD a un Gemstone por ejemplo, esto de luchar contra >> la >> > > >> > "basura", es >> > > >> > > > el principal problema a atender/atacar al administrarla, en >> una >> > > BBDD la >> > > >> > > > basura existe por siempre y no nos damos cuenta (hasta que >> > > conectamos >> > > >> > un >> > > >> > > > producto BI y saltan todos los sapos). >> > > >> > > > De hecho, no tener esta educación en nuestra sociedad entera >> nos >> > > lleva >> > > >> > a >> > > >> > > > enfrentarnos que tenemos al planeta completo contaminado y no >> > > sabemos >> > > >> > ni que >> > > >> > > > hacer. >> > > >> > > > Smalltalk es demasiado avanzado para que todos lo entiendan, >> eso >> > > es >> > > >> > algo >> > > >> > > > que hay que aceptar. Es una falta de educación en el fondo. >> > > >> >> > > >> > > > Saludos, >> > > >> > > > Hernán.- >> > > >> >> > > >> > > > On Wed, Nov 11, 2009 at 3:14 PM, Bruno Buzzi Brassesco < >> > > >> > > > [email protected]> wrote: >> > > >> >> > > >> > > >> Es una percepción general de la gente de los lenguajes >> > > tradicionales. >> > > >> > > >> En la software factory que trabajaba tambien pensaban asi lo >> que >> > > >> > conocían >> > > >> > > >> (aunque se a de nombre) Smalltalk. >> > > >> >> > > >> > > >> Pero no pienses que en C# no podes meter la pata, trabaje >> con un >> > > >> > Framework >> > > >> > > >> en C# que era algo lamentable, no voy a poner nombres, pero >> la >> > > gente >> > > >> > que >> > > >> > > >> construyo esa cosa, era "gurus" de M$. Y mira que es >> imposible >> > > que te >> > > >> > > >> imagines el dolor de los programadores cuando querian >> construir >> > > un >> > > >> > sistema >> > > >> > > >> usando esa cosa. >> > > >> >> > > >> > > >> El problema de C# en este caso es que el Framework estaba >> "bien >> > > >> > pensando" >> > > >> > > >> desde el punto de vista de la arquitectura, cuando llevas >> esa >> > > "buena >> > > >> > idea" >> > > >> > > >> de arquitectura a la practica y construis, el ambiente de >> > > desarrollo >> > > >> > te >> > > >> > > >> queda algo que no se puede describir con palabras (un >> desastre). >> > > >> > > >> Y esto es porque C# no es homogeneo en Smalltalk no hay >> > > diferencia >> > > >> > entre >> > > >> > > >> arquitectura y ambiente de desarrollo, hay objetos de... >> > > >> >> > > >> > > >> En broma les decia los programadores de C#, eso que tenes >> ahí >> > es: >> > > "un >> > > >> > > >> compilador + un combo box". >> > > >> > > >> Eso es C#, un compilador (c#) y ComboBox que te hace un goto >> al >> > > codigo >> > > >> > > >> fuente. Y la librería de C# es usanda como un gran >> repositorio >> > de >> > > >> > > >> procedimientos, asi usan C# todos los programadores, incluso >> los >> > > Mega >> > > >> > Mega >> > > >> > > >> MS Mega Seniors Expert. >> > > >> >> > > >> > > >> En la tecnologia tradicional lo que llaman "orientado a >> objetos" >> > > NO se >> > > >> > > >> acerca ni por asomo a como se trabaja en Smalltalk, es muy >> > > diferente >> > > >> > la >> > > >> > > >> forma de resolver problemas y construir sistemas. >> > > >> > > >> La confusion radica en que se usa el mismo termino: " >> orientado >> > a >> > > >> > objetos" >> > > >> >> > > >> > > >> Saludos, >> > > >> > > >> Bruno >> > > >> >> > > >> > > >> -----Original Message----- >> > > >> > > >> From: [email protected] [mailto: >> > > >> > > >> [email protected]] >> > > >> > > >> On Behalf Of Rusty >> > > >> > > >> Sent: Wednesday, November 11, 2009 4:47 PM >> > > >> > > >> To: ClubSmalltalk >> > > >> > > >> Subject: [clubSmalltalk] Re: DIscusion polemica >> > > >> >> > > >> > > >> No sé si es lo que lo mató, o si siquiera está muerto. >> > > >> > > >> Pero si sé que estoy de acuerdo con el comentario. >> > > >> >> > > >> > > >> Smalltalk es el paraíso de los buenos programadores. >> > > >> > > >> Pero también es el paraíso para el desprolijo y el que ata >> con >> > > >> > > >> alambre. >> > > >> > > >> Y eso último es jo-di-do. >> > > >> >> > > >> > > >> Salutes. >> > > >> >> > > >> > > >> Rusty. >> > > >> >> > > >> > > >> On 10 nov, 10:31, GallegO <[email protected]> wrote: >> > > >> > > >> > Se desato una discusion en el blog de cincom y rescato un >> > > comentario >> > > >> > > >> > que quiero compartir: >> > > >> >> > > >> > > >> > Completo enhttp://bit.ly/Uu517 >> > > >> >> > > >> > > >> > ...but I think the context of the quote is being >> > misinterpreted >> > > >> > > >> > somewhat. My impression from the video wasn't that Bob >> was >> > > >> > > >> > misrepresenting Cunningham's meaning, but just that he >> wasn't >> > > >> > > >> > explaining it very well. >> > > >> > > >> > 'What killed Smalltalk is that it was just too easy to >> make a >> > > mess." >> > > >> > > >> > I think that's absolutely true, but it isn't necessarily a >> bad >> > > >> > thing. >> > > >> > > >> > The truth is that in Smalltalk it's often easier to do >> > > anything, >> > > >> > both >> > > >> > > >> > good and bad. It's rather like saying that the problem >> with a >> > > >> > > >> > motorcycle, compared to a bicycle, is that it's just too >> easy >> > > to go >> > > >> > > >> > too fast and wreck one. With programming languages, as >> with >> > > bikes, >> > > >> > if >> > > >> > > >> > you give a powerful tool to an undisciplined, >> inexperienced >> > > user, >> > > >> > they >> > > >> > > >> > can cause a lot of damage. >> > > >> > > >> > If the only vehicle you give someone is a one-gear bicycle >> > with >> > > >> > street >> > > >> > > >> > tires and training wheels, it'll be really hard for them >> to >> > > hurt >> > > >> > > >> > themselves, but they're never going to go very far or very >> > > fast, >> > > >> > > >> > either. >> > > >> >> > > >> > > >> > Saludos >> > > >> > > >> > GallegO >> > > >> >> > > >> > > >> No virus found in this incoming message. >> > > >> > > >> Checked by AVG -www.avg.com >> > > >> > > >> Version: 8.5.424 / Virus Database: 270.14.53/2486 - Release >> > Date: >> > > >> > 11/07/09 >> > > >> > > >> 07:38:00- Ocultar texto de la cita - >> > > >> >> > > >> > > - Mostrar texto de la cita -- Ocultar texto de la cita - >> > > >> >> > > >> - Mostrar texto de la cita - >> > > > > >> > > > >> > > >> > > > >> > > >> > >> > > >> > >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
