DIscusion polemica

[GallegO]

Se desato una discusion en el blog de cincom y rescato un comentario
que quiero compartir:

Completo en http://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

[Andres Valloud]

Ehhh, que se yo... me parece que lo miran desde un punto de vista
donde las opciones son limitadas por definicion.

http://blogten.blogspot.com/2009/05/wards-comment.html

[Rusty]

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 <fxgall...@gmail.com> wrote:
> Se desato una discusion en el blog de cincom y rescato un comentario
> que quiero compartir:
>

> Completo enhttp://bit.ly/Uu517

[Andres Valloud]

En realidad, todos los lenguajes tienen un paraiso asi. Quiza el tema
es que con Smalltalk es mas facil hacer cosas lindas, asi que el
contraste entre lo bueno y lo no tan bueno es mas evidente.

[Hernan Wilkinson]

en smalltalk podes hacer cosas más desprolijas que en c? que en c++? que en java?? no me lo creo... no entiendo por qué, qué cosas más desprolijas podés hacer?

[Mariano Abel Coca]

No entendés nada Hernán! Lo que pasa es que como en Smalltalk no tenés chequeo de tipos podés hacer cualquier cosa!

Obviamente no cuenta el hecho de que en c/c++ tenés que manejar la memoria a mano y con casteos podés hacer siempre cualquier cagada. Esos son sólo detalles... :D

Abrazo!

Mariano.

[Bruno Buzzi Brassesco]

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

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

[Rusty]

En esos lenguajes tenés muchas reglas que limitan la cualquierosidad
del código.
Un ejemplo conciso es el tipado.
Si en un lenguaje tipado definís un parámetro como int, vos después
podés hacer todos los chanchuyos que quieras.
Pero sabés que ahí va a caer un entero.
En ST viene un objeto. Puede ser un entero. Puede ser nil. Puede ser
true, false o unCocodrilo.

Imaginate programar un sistema con bronca. Quién lo programa piensa:
Tengo BRONCA de estar haciendo esto. Voy a hacerlo de la forma mas
rápida, mas sucia y mas directa posible.
En otros lenguajes por lo menos esa persona tiene que regirse por
reglas.
En Smalltalk el límite es el infierno.

Tal vez es un poco lo que comenta Andrés.
En Smalltalk hay cosas que no puedo ver.
Cuando veo nudos en otros lenguajes bueno ... realmente no me
horroriza, al fin y al cabo es C ! :P

[Andres Valloud]

El costo de esas reglas es que el costo de cambiar un programa bien
escrito en (por ejemplo) C tiende a ser muchisimo mas grande que el
costo de cambiar un programa bien escrito en Smalltalk. Quiza en
aplicaciones comparativamente poco complejas como websites que duran
pocos años antes de re-escribirse de cero no se nota. De hecho, si la
re-escritura se considera efectiva, entonces el software no tenia
tanto contenido intelectual como para que fuera mas valioso
preservarlo. Pero, apenas uno tiene problemas comparativamente mas
complejos, entonces no se puede andar re-escribiendo todo de cero
porque el costo es carisimo. Ahi es donde las ventajas de Smalltalk
brillan, porque en esos casos es mucho mejor (dado un programa
relativamente bien escrito) bajar el costo del cambio para no tener
que terminar con una re-escritura.

Lo que es medio triste es que aun hoy parece que inventamos lenguajes
desde cero todos los años para resolver problemas comparativamente
simples. El tema de fondo es que, la mayoria de las veces, no
escribimos software comparativamente sofisticado. O sea, si Rails
sirve para describir una seccion grande del software que se escribe,
bueno... eso es todo lo que vamos a hacer con nuestros enesimos
centros de computo cuyo consumo electrico se mide en mega watts por
hora? ABM en un browser? Ahi es donde miro el video de la demo de
Doug Engelbart y lo que siento es un cachetazo: desde 1968 hasta aca,
pareciera que no hicimos un pomo.

http://video.google.com/videoplay?docid=-8734787622017763097#

Entonces... si medimos nuestra capacidad con una vara como Rails,
entonces a la gente que cumple esas metas comparativamente poco
exigentes les puede parecer que Smalltalk no sirve para nada. Pero,
aunque parezca mentira, no todo en el mundo es hacer paginas web.

Andres.

[Hernan Wilkinson]

Que tal Rusty,

 sinceramente no concuerdo para nada con lo que estás diciendo. Por un lado estás confundiendo qué tan fuerte es el chequeo de tipos con cuándo se hace el chequeo de tipos.

 Smalltalk hace chequeo de tipos fuerte y lo hace dinámicamente. Esto significa que si en una variable donde estas esperando un entero pones un boolean, no te avisa en el momento de la asignación de la variable pero te avisa en el momento de mandarle un mensaje al objeto y no hay manera de hacerle creer a nadie que un boolean puede ser un entero.

 C tiene chequeo de tipos débil pero estático. Idem C++. Esto significa que si en una variable donde estas esperando un entero pones un boolean, el COMPILADOR te avisa del supuesto error, por eso se denomina estático. Pero es débil porque con un simple casteo podes bypasear ese chequeo y asignale el boolean a la variable para que luego todo se vaya a la mierda sin saber porque.

 Java tiene chequeo fuerte y estático, al igual que C#, pero como no es posible realizar todos los chequeos de manera estática existen excepciones como NullPointerException que solo se producen en tiempo de ejecución, o sea, de manera dinámica finalmente...

 Por lo tanto, lo que no hay duda es que el chequeo de tipos debe ser fuerte y eso es justamente lo que hace Smalltalk.

 Si pueden haber discusiones de si es mejor hacerlo de manera estática o dinámica, pero si te gusta la estática tené en claro que no existe chequeo de tipos estático que te de "seguridad" completa (en realidad falsa seguridad) porque hay verificaciones que se deben hacer dinámicamente, ni siquiera Eiffle que le rompe el c... al java y c# en chequeo de tipos puede asegurar que todos los errores se encuentren en tiempo de compilación.

 Que el chequeo de tipos sea dinámico no significa que podes hacer cualquier cosa! lo que importa es si es fuerte o débil! podes hacer cualquier cosa con chequeo de tipo débil como en c/c++

 Y si sentís que con chequeo de tipo dinámico podes hacer cualquier cosa, es porque nunca hiciste un sistema en serio con un lenguaje con chequeo fuerte y dinamico de tipos como Smalltalk o lo hiciste mal, sin probar lo que hiciste.

 Perdoná que sea tan duro en mis observaciones, pero estoy cansado de ver estos comentarios generados por errores conceptuales.

 Saludos,

 Hernán.

[Hernán Galante]

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.

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

[Mariano Abel Coca]

Simplemente para aportar un detalle más.

Saludos,

Mariano.

2009/11/12 Hernán Galante <hernan....@gmail.com>

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 :)
 

[Hernán Galante]

Estamos de acuerdo, las ventajas que presenta Smalltalk frente a otras metodologias de construcción son impresionantes, pero explicaselo a un programador C# o Java o Whatever ... :-P

2009/11/12 Mariano Abel Coca <mariano...@gmail.com>

[dcoro...@gmail.com]

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 <marianoabelc...@gmail.com> wrote:
> Simplemente para aportar un detalle más.
>
> Saludos,
>
> Mariano.
>

> 2009/11/12 Hernán Galante    <hernan.gala...@gmail.com>

> >> 07:38:00- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

[Gabriel Brunstein]

Diego, me interesa tu punto de vista, por qué afirmas que es nociva la seguridad que te dan los tests?

2009/11/12 dcoro...@gmail.com <dcoro...@gmail.com>

[Rusty]

Hola Hernan.
No veo donde lo que escribí contradiga lo que dijiste vos, pero vamos
que lo del tipado fué sólo un ejemplo para ilustrar mi punto de vista
(y tema principal del thread) que es que la misma libertad que ofrece
Smalltalk puede usarse para 'bien' y para 'mal'.
De todas formas gracias por la clase gratuita sobre el tema, me quedó
claro que leíste bastante sobre él.

Y si por el sentimiento de una persona inferís el nivel de seriedad o
correctitud de sus sistemas no estás siendo duro, estás siendo
adivino.
Para esoterismo smalltalker hay otra lista. Creo que todavía existe,
no estoy seguro que haya mucha gente :D

Salutti.

Rusty.

[Hernan Wilkinson]

2009/11/12 Rusty <oku...@gmail.com>

Hola Hernan.
No veo donde lo que escribí contradiga lo que dijiste vos, pero vamos
que lo del tipado fué sólo un ejemplo para ilustrar mi punto de vista

peor es un mal ejemplo y por lo tanto te hace inferir conclusiones erroneas
 

(y tema principal del thread) que es que la misma libertad que ofrece
Smalltalk puede usarse para 'bien' y para 'mal'.

como todo en la vida, y yo prefiero la libertad a no tenerla.
 

De todas formas gracias por la clase gratuita sobre el tema, me quedó
claro que leíste bastante sobre él.

de nada, un placer
 

Y si por el sentimiento de una persona inferís el nivel de seriedad o
correctitud de sus sistemas no estás siendo duro, estás siendo
adivino.

no fue sentimiento, fue lo que escribiste. Por ejemplo pusiste "En Smalltalk el límite es el infierno", pero peor es en c/c++, etc. O sea, no concuerdo con tu conclusión y además sucede todo lo contrario.

Para esoterismo smalltalker hay otra lista. Creo que todavía existe,
no estoy seguro que haya mucha gente :D

En eso estoy de acuerdo :-)
 

[dcoro...@gmail.com]

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 <gab...@gmail.com> wrote:
> Diego, me interesa tu punto de vista, por qué afirmas que es nociva la
> seguridad que te dan los tests?
>

> 2009/11/12 dcorone...@gmail.com <dcorone...@gmail.com>

> > > - Mostrar texto de la cita -- Ocultar texto de la cita -

[GallegO]

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?
¿Cuando desarrollas el producto si es que tenes que escribir tantos tests?
Es decir, las respuestas seguramente sean simples, pero las ecuaciones
en tiempo y dinero no.

Para mi, y para mi trabajo actual, no es tan simple.

Saludos
GallegO


El día 12 de noviembre de 2009 18:58, dcoro...@gmail.com
<dcoro...@gmail.com> escribió:

[Hernan Wilkinson]

2009/11/12 dcoro...@gmail.com <dcoro...@gmail.com>

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.

yo creo que no... :-)

 

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.

Los test "usan" el sistema, pero el sistema ni se entera de los test. El acoplamiento va de los test al sistema (creo que es lo que decis) de la misma manera que existe el acoplamiento del "usuario" hacia el sistema... no estás haciendo más que simular un usuario con los tests si querés verlo así, por lo tanto a mi me parece buenísimo.

 

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.

No es tan así, depende de que cambios hagas, cuanto impacte, etc.

De última, es mejor arreglar test que arreglar errores en producción no?

No entiendo por qué la gente se preocupa tanto por tener que manterner tests. Si están bien hechos, no cuesta y la seguridad que te dan paga varias veces lo que te lleva hacerlo y mantenerlo.

Mi experiencia, en un sistema donde hicimos 17000 tests, nunca tuvimos un problema grave de parar un release por modificar test, de última asumiamos el riesgo de salir con esos test fallando para ir arreglandolos de a poco

 

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.

por qué? de vuelta, habiendo hecho tdd seriamente, es así. A ver, de una manera u otra tenes que testear cualquier cambio que hagas, o lo haces con test automatizados, o lo haces a mano o lo hace el usuario en producción... 

 

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,

entonces no estás haciendo tdd en serio... y ese gerente o jefe que no te deja hacer refactorizacion si tenés tests, menos te va a dejar si no tenés tests! va a decir "don't fix it if it aint break"! o sea, un cagón total.... entonces esto no es un problema de tdd sino de ese tipo

 

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.

pero los test son workspaces que quedan en el tiempo... nunca perdés lo que hiciste y podés hacer regresión. A un workspace una vez que terminaste con tus pruebas (o sea, tests) lo perdiste... o sea, tdd te sirve para hacer programación exploratoria tanto como un workspace y es mejor porque queda todo lo que explorarte para asegurarte en cada cambio que hagas...

 

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.

De vuelta, no estoy de acuerdo. Los tests son primero casos concretos que te permiten aprender (como lo que haces en el workspace) y luego son test. El nombre TDD es misleading porque parece que lo principal es el test, pero la verdad es que no, la verdad es que lo más importante es que haces desarrollo exploratorio, iterativo, incremental y además, te asegurar de que funcione bien y la computadora te ayuda en cada cambio que hagas de avisarte si cometiste algún error.

 

saludos,

Hernan.

[Hernan Wilkinson]

2009/11/12 GallegO <fxga...@gmail.com>

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.

[GallegO]

Hernan:

Conociendo ti experiencia en el sistema XTrade (creo que se llama así)

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

Uds realizaron el desarrollo de ese sistema desde la primera linea de
codigo con tests o existio un momento en el cual empezaron a
realizarlos y no pararon más?.

Me gustaria saber tambien cual es el nivel de refactoring que suelen
aplicarle a ese sistema, si es que es normal introducir cambios que
modifiquen protocolos considerablemente, jerarquias, renombramiento de
clases, en fin pequeñas o grandes bombas :)

Tienen testeada la GUI?

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

Bueno, pero eso depende de cuanto cambie el sistema y como este hecho.
Yo puedo decir que si un sistema está bien hecho y basado en conceptos
simples, por mas que no tenga tests te va a traer menos problemas que
uno totalmente testeado, complicado y obeso.

Lo bueno de los tests supongo es asegurar la calidad o correctitud del sistema.
En ningún momento nos asegura no tener problemas grosos.
Bueno, igual creo que es lo que vos quisiste decir tambien.

Saludos
GallegO

[Hernan Wilkinson]

2009/11/13 GallegO <fxga...@gmail.com>

Hernan:

Conociendo ti experiencia en el sistema XTrade (creo que se llama así)

Que haces Gallego,
si, se llama así

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

Uds realizaron el desarrollo de ese sistema desde la primera linea de
codigo con tests o existio un momento en el cual empezaron a
realizarlos y no pararon más?.

Tuvimos la suerte de emperzar un sistema desde cero y lo hicimos usando tdd desde el principio, ese es el mejor caso que se puede dar.
Si ya tenes un sistema, empezar a hacar tdd es muy dificil puesto que el sistema està seguramente muy acoplado y por lo tanto es muy difìcil testearlo...
 

Me gustaria saber tambien cual es el nivel de refactoring que suelen
aplicarle a ese sistema, si es que es normal introducir cambios que
modifiquen protocolos considerablemente, jerarquias, renombramiento de
clases, en fin pequeñas o grandes bombas :)

uh! hicimos de todos, rompimos y volvimos a hacer muchas cosas, cambiamos cosas chiquitas, etc. todo lo que se te ocurra, pero nunca dejamos de hacer tdd porque justamente eso nos permitía hacer esos cambios! sino, no había manera de que nos animemos...
 

Tienen testeada la GUI?

En un momento empezmaos a hacer test automatizados de ui pero tuvimos que dejarlo por unos problemas técnicos y luego falta de gente, pero cuando lo tuvimos ayudó mucho y siempre quisimos volver a hacerlo
 

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

Bueno, pero eso depende de cuanto cambie el sistema y como este hecho.
Yo puedo decir que si un sistema está bien hecho y basado en conceptos
simples, por mas que no tenga tests te va a traer menos problemas que
uno totalmente testeado, complicado y obeso.

si y no, todo depende no? porque también hay que pensar en como cambia el sistema, quien lo cambia, que rotación de gente tenes, etc. y tener test te ayuda a transmitir mejor la idea de como se hicieron las cosas, asegurarte que no metan la pata, etc. que se yo, para mi siempre paga.
 

Lo bueno de los tests supongo es asegurar la calidad o correctitud del sistema.
En ningún momento nos asegura no tener problemas grosos.
Bueno, igual creo que es lo que vos quisiste decir tambien.

a que te referis con problemas grosos?
Un test te asegura que lo que testeaste funciona, nada mas, pero tdd es más que hacer test, es ayudarte a explorar el dominio, ha hacer desarrollo exploratorio, interativo, incremental y a tener resultados ràpido..
 
Un abrazo,
 Hernan.

Saludos
 GallegO

[dcoro...@gmail.com]

On 13 nov, 05:33, Hernan Wilkinson <hernan.wilkin...@gmail.com> wrote:
> 2009/11/12 dcorone...@gmail.com <dcorone...@gmail.com>

>
>
>
> > 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.
>
> yo creo que no... :-)

Aclaro un poquito, dije algo un poco fuerte y me arrepiento :-), pero
te pongo un ejemplo en donde veo cierta ingenuidad o hipocresía
smalltalkera al diseñar: Suponete que creas una clase Person con un iv
#phones, como es Smalltalk #phones no lleva tipo y hasta presupones
que podría ser un String, una Collection o un objeto muy complejo que
se conecte a 44 empresas de telefonía. Total como es Smalltalk no debo
especificar tipo. Pero a los 10 minutos estás dibujando un textBox en
una view para meter eso, y luego tal vez lo guardas en un varchar de
una base de datos y en otro momento lo mandás a un reporte o html. En
todos estos usos de #phones, que usan gran parte del protocolo de
String, estás diciendo implícitamente que #phones es un String, lo vas
diciendo de a poco y desordenadamente. Además luego de un tiempo te
das cuenta que estaba bien que haya sido un String y que es poco
rentable sofisticar a #phones, porque no es tan importante en el
sistema y no querés invertir tiempo en hacer el megaobjeto
superpolimórfico para algo tan poco relevante. Entonces pienso que si
se hubiese aclarado en algún momento, de alguna manera blanda (no digo
tipar estaticamente ni nada tan drástico) entonces ni siquiera se
hubiese tenido que dibujar el textBox porque se podría haber dibujado
solo, el campo varchar de la tabla se hubiese generado solo y todas
las demas interacciones hubiesen sido menos costosas.
Yendo un poco mas lejos, creo que en Smalltalk hay una característica
que suele quedar desapercibida y genera problemas de diseño. Y es el
hecho de que existe una distancia muy grande en términos de
abstracción entre una clase y un objeto. Esto es bueno creo, pero
conviene tenerlo muy presente porque es necesario llenar ese gap
ordenadamente. Por ejemplo en Java/C++/.NET/etc. las clases son mas
concretas porque son tipadas, porque hay cosas privadas, publicas,
protegidas, amigas y quien sabe cuanto invento mas. Son mas concretas
porque dicen mas acerca de sus instancias, lamentablemente. Por el
contrario en Smalltalk los objetos son mas concretos, no se me ocurre
nada mas concreto que evaluar 3+4. Entonces lo que creo es que esa
distancia es necesaria considerarla al momento de hacer cosas como
interfaces con otros sistemas, GUIs, persitencia o distribución.
Ejemplo: hacer un generador de tablas para persistencia relacional en
Java es mas simple porque ya se qué tipo de datos ponerle a los
campos. Hay muchos ejemplos mas en esta línea.

> > 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.
>
> Los test "usan" el sistema, pero el sistema ni se entera de los test.

Ningún objeto de Smalltalk se entera de quien lo usa hasta que recibe
un mensaje.

El
> acoplamiento va de los test al sistema (creo que es lo que decis) de la
> misma manera que existe el acoplamiento del "usuario" hacia el sistema...

Un usuario es una entidad muchisimo mas adaptativa que una batería de
tests el grado de acoplamiento es ínfimo comparado con un test.

no
> estás haciendo más que simular un usuario con los tests si querés verlo así,
> por lo tanto a mi me parece buenísimo.

Los tests expresan lo que el programador cree que hará o debe hacer un
usuario, es muy distintinto.

> > 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.
>
> No es tan así, depende de que cambios hagas, cuanto impacte, etc.
> De última, es mejor arreglar test que arreglar errores en producción no?

Supongo que coincidimos que para estar bien en producción es necesario
lograr estabilidad. Creo que esa estabilidad se logra antes y con
menos esfuerzo si no tengo a los tests como lastre, si puedo alterar
mucho y muy seguido al sistema con un bajo costo.

> No entiendo por qué la gente se preocupa tanto por tener que manterner
> tests. Si están bien hechos, no cuesta y la seguridad que te dan paga varias
> veces lo que te lleva hacerlo y mantenerlo.

Hace algunos años, con gente de esta lista :-), hicimos una clase
FixedDecimal para instanciar números que respresenten dinero. En estos
casos creo que si es aconsejable meterle tests, como en todo caso en
donde la especificación es muy clara. Agregamos todos los que
encontramos (creo que eran los ANSI) y se nos ocurrieron, daba todo
verde y todos "demasiados" tranquilos. Hace poco encontré un error
aritmético en dicha clase que puede que haya producido diferencias
monetarias en TODOS los sistemas que hice hasta ahora. Semejante
cagadón que nos mandamos hubiese sido mas evidente sin los tests,
porque me hubiese asignado mas tiempo a revisar esa clase en lugar de
escribir tests. Porque la incertidumbre hubiese jugado a favor de
factorizar y emprolijar todo lo posible una clase tan crítica.

> Mi experiencia, en un sistema donde hicimos 17000 tests, nunca tuvimos un
> problema grave de parar un release por modificar test, de última asumiamos
> el riesgo de salir con esos test fallando para ir arreglandolos de a poco

Lo que habría que evaluar no es cuantos problemas tiene dicho sistema,
sino cuánto cambió realmente y a qué costo.

> > 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.
>
> por qué? de vuelta, habiendo hecho tdd seriamente, es así. A ver, de una
> manera u otra tenes que testear cualquier cambio que hagas, o lo haces con
> test automatizados, o lo haces a mano o lo hace el usuario en producción...

Cuando el sistema adquiere un nivel de estabilidad y las entidades mas
importantes un grado de abstracción importante, entonces los sistemas
tienden a tener dos tipos de errores: inofensivos o cuelgues totales.
Ambos tipos de errores no suelen ser nocivos en producción y en ese
punto te diría qeu si, que se haga en producción.

> > 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,
>
> entonces no estás haciendo tdd en serio... y ese gerente o jefe que no te
> deja hacer refactorizacion si tenés tests, menos te va a dejar si no tenés
> tests! va a decir "don't fix it if it aint break"! o sea, un cagón total....
> entonces esto no es un problema de tdd sino de ese tipo

No es solo lo que te diga tu jefe, es un tema económico, es mas caro
factorizar con tests.

Coincido en algunas cosas que decis, pero creo que los tests deben
usarse solo en aquellas partes en donde la definición está muy clara
de entrada. Por ejemplo si vas a implementar TCP, te bajás el rfc y
escribís ese documento en forma de tests. Pero si te ponés a escribis
tests sobre cómo manejar el buffer o cualquier otra cosas que no hace
a la especificación concreta, entonces creo que estás limitando la
capacidad de laburo que te da Smalltalk.

> saludos,
> Hernan.

Saludos, y aprovecho para agradecerte a vos y a los demás que hacen
Smalltalks2009. No podré asistir pero me alegra que haya gente que
ponga tanto esfuerzo en algo que cada año mejora su calidad.

> ...
>
> leer más »- Ocultar texto de la cita -

[GallegO]

>> Lo bueno de los tests supongo es asegurar la calidad o correctitud del
>> sistema.
>> En ningún momento nos asegura no tener problemas grosos.
>> Bueno, igual creo que es lo que vos quisiste decir tambien.
>
> a que te referis con problemas grosos?

Para mi un problema groso es algo que ya no se puede cambiar* y que
impacta en muchos lugares en el sistema.
Entonces, todo puede tener test y anda fenomeno, pero es una gran caca.
Claro, podes decirme que como tenes los tests, podes cambiar todo lo
que está mal, y es cierto.

A lo que apunto, y es algo que se VENDE hoy por hoy en el ambiente de
desarrollo, es que si un sistema esta totalmente testeado, es un
sistema bueno.
Como vos decís, Y HAY QUE LEER MUY BIEN, lo testeado funciona.
Eso no quiere decir que el sistema funcione, ni que el sistema sea
"bueno", si esto se puede medir de alguna forma, más que con la
opinión de los clientes.

Y creo que ese es el punto donde por ahí algunos disentimos. Aún así
todo esta relacionado en alguna u otra forma. Un sistema sin errores
va a tener clientes satisfechos siempre y cuando sea económico y en
tiempo.

Es algo pendiente para mi darle una oportunidad al TDD. Las veces que
lo intenté quizás no puse el suficiente esfurzo y como Diego sentí que
un workspace era más simple. Obviamente el debugger y todo eso se usa,
solo que no me banco hacer tests (por ahora) antes que otra cosa. Se
ve que me falta un ingrediente.

Saludos
GallegO

PD. Seguro es tarde pero estaria bueno una demo tuya en Smalltalks,
donde te proponemos un sistema en el momento y comenzas a modelarlo e
implementarlo de 0 con TDD. Nosotros miramos nomas :) y vemos como
hacés.

[Guillermo Sapaya]

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:hernan.w...@gmail.com]
To: clubsm...@googlegroups.com
Sent:
Fri, 13 Nov 2009 09:37:06 -0200
Subject: [clubSmalltalk] Re: DIscusion
polemica

> 2009/11/12 GallegO <fxga...@gmail.com>
>
> >
> > 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, dcoro...@gmail.com
> > <dcoro...@gmail.com> 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.
> > >

> > >> > > >> 07:38:00- Ocultar texto de la cita -

[Hernan Wilkinson]

2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>

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.

pero tdd es acerca de prototipar! es acerca de tener algo funcionando rápido... no se cómo están haciendo tdd pero sirve justamente para lo que vos estás buscando...
 

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.

Si solo refactorizas, no tenes que cambiar ningun tests. Los refactorings no alteran la ejecuciòn del sistema.
Si modificas el modelo, por ahí si tenes que modificar tests, dependiendo de que cambio hayas hecho, pero no es el comun de los casos... de vuelta, no entiendo porqué tanto problema por el mantenimiento de los tests, no consume tanto!
 

Repito, para mí. Seguramente en otros casos (como en el tuyo) les resulta satisfactorio.

si, a mi si.
 

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.

Tdd no reemplaza los test funcionales o exploratorios o de ui, etc. que deben hacer los testers
Pero tdd no es solo hacer test unitarios, todo lo contrario y eso es una confusión muy grande. Tdd no es bottom-up, es top-down porque justamente es exploratorio. Con tdd tambien haces test funcionales, de user story que además son los más interesantes y los que más aportan.
 

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.

Estoy de acuerdo, eso va por otro camino. Tdd no reemplaza eso.
 

En fin, es un tema para largo pero bueno, por lo menos expuse mi opinión.

Un abrazo,
Hernan.

[Mariano Abel Coca]

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 <gsa...@infoil.com.ar>

[Hernan Wilkinson]

Me perdi con que las clases son mas concretas en java que en smalltalk, o que en smalltalk los objetos son mas concretos... no se a que te referis, creo que tenemos raices muy distintas sobre el significado de estas cosas

> > 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.
>
> No es tan así, depende de que cambios hagas, cuanto impacte, etc.
> De última, es mejor arreglar test que arreglar errores en producción no?

Supongo que coincidimos que para estar bien en producción es necesario
lograr estabilidad. Creo que esa estabilidad se logra antes y con
menos esfuerzo si no tengo a los tests como lastre, si puedo alterar
mucho y muy seguido al sistema con un bajo costo.

Si tenes tests como lastre, no estás haciendo bien tdd.
 

> No entiendo por qué la gente se preocupa tanto por tener que manterner
> tests. Si están bien hechos, no cuesta y la seguridad que te dan paga varias
> veces lo que te lleva hacerlo y mantenerlo.

Hace algunos años, con gente de esta lista :-), hicimos una clase
FixedDecimal para instanciar números que respresenten dinero. En estos
casos creo que si es aconsejable meterle tests, como en todo caso en
donde la especificación es muy clara. Agregamos todos los que
encontramos (creo que eran los ANSI) y se nos ocurrieron, daba todo
verde y todos "demasiados" tranquilos. Hace poco encontré un error
aritmético en dicha clase que puede que haya producido diferencias
monetarias en TODOS los sistemas que hice hasta ahora. Semejante
cagadón que nos mandamos hubiese sido mas evidente sin los tests,
porque me hubiese asignado mas tiempo a revisar esa clase en lugar de
escribir tests. Porque la incertidumbre hubiese jugado a favor de
factorizar y emprolijar todo lo posible una clase tan crítica.

o por ahí hubiese sido mejor hacer mejores tests... de vuelta, un test solo asegura que lo que testeas funciona, si no testeaste algo no te dice nada.
Igual, no te olvides que tdd dice justamete "refactorizar y mejorar el modelo" por lo tanto esa revisión que comentas la hubiese hecho si haces tdd correctamente

> Mi experiencia, en un sistema donde hicimos 17000 tests, nunca tuvimos un
> problema grave de parar un release por modificar test, de última asumiamos
> el riesgo de salir con esos test fallando para ir arreglandolos de a poco

Lo que habría que evaluar no es cuantos problemas tiene dicho sistema,
sino cuánto cambió realmente y a qué costo.

uh! cuanto cambio? muchisimo! tiene cerca de 10000 clases, hace unos años creo que 800 mil lineas de codigo y se le esta agregando funcionalidad constantemente, por ejemplo en el congreso van a mostrar toda la parte de curvas y riesgo.. o sea, cambiar, cambio muchisimo y lo sigue haciendo.
 

> > 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.
>
> por qué? de vuelta, habiendo hecho tdd seriamente, es así. A ver, de una
> manera u otra tenes que testear cualquier cambio que hagas, o lo haces con
> test automatizados, o lo haces a mano o lo hace el usuario en producción...

Cuando el sistema adquiere un nivel de estabilidad y las entidades mas
importantes un grado de abstracción importante, entonces los sistemas
tienden a tener dos tipos de errores: inofensivos o cuelgues totales.
Ambos tipos de errores no suelen ser nocivos en producción y en ese
punto te diría qeu si, que se haga en producción.

un cuelge total en producción? guau.. bueno, pensamos muy distinto... no se si tiene sentido conversar sobre esto con ideas bàsicas tan distintas.
 

> > 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,
>
> entonces no estás haciendo tdd en serio... y ese gerente o jefe que no te
> deja hacer refactorizacion si tenés tests, menos te va a dejar si no tenés
> tests! va a decir "don't fix it if it aint break"! o sea, un cagón total....
> entonces esto no es un problema de tdd sino de ese tipo

No es solo lo que te diga tu jefe, es un tema económico, es mas caro
factorizar con tests.

de vuelta, no estás poniendo todo en la ecuación. como estàs seguro que es más caro factorizar con tests? estàs teniendo en cuenta los errores que surgen por hacer cambios que te evitar con tdd y no te evitas por no hacerlo?
Yo creo que estamos opinando en base a experiencias y mi experiencia con tdd es buena. Seguramente la tuya es mala y seguis diciendo que cambiar el modelo con tdd cuesta, bueno, mi respuesta a eso es que seguramente los tests no eran buenos o la tecnologìa que usaste no era buena, por que de vuelta, eso a mi no me paso
 

claro que no! tenes que hacer tdd cuando no tenes ni idea sobre lo que estás modelando! justamente es una de las mayores ventajas!
 

Por ejemplo si vas a implementar TCP, te bajás el rfc y
escribís ese documento en forma de tests. Pero si te ponés a escribis
tests sobre cómo manejar el buffer o cualquier otra cosas que no hace
a la especificación concreta, entonces creo que estás limitando la
capacidad de laburo que te da Smalltalk.

De vuelta no coincido, cuando hago tdd es cuando uso smalltalk a full, cambio cosas en el debugger, levanto inspectores,  modifico objetos, etc.

Saludos,
Hernan.

[Hernan Wilkinson]

PD. Seguro es tarde pero estaria bueno una demo tuya en Smalltalks,
donde te proponemos un sistema en el momento y comenzas a modelarlo e
implementarlo de 0 con TDD. Nosotros miramos nomas :) y vemos como
hacés.

Ningun problema, lo hacemos el sabado por la tarde durante el pharo sprint, me encatarìa hacerlo, seguro nos va a servir a todos.

Un abrazo,
Hernan.
 

[Hernan Wilkinson]

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 <mariano...@gmail.com>

[GallegO]

Yo me prendería, aunque no se si da para mezclarlo con el día del
Pharo sprint, medio que nos van a mandar a cag.ar
No se me ocurre que sería hacer algo groso.
Convengamos que seria algo sobre tdd suponiendo que ya conocemos el
uso de sunit.
Estaría bueno.

Saludos
GallegO

El día 13 de noviembre de 2009 14:03, Hernan Wilkinson
<hernan.w...@gmail.com> escribió:

[Andres Valloud]

Tenia ganas de contestar a este thread...

Para mi, no se pueden escribir todos los tests de antemano, porque eso
implicaria que uno conoce el problema a resolver por completo. Rara
vez es asi. Por eso, al principio prefiero escribir tests funcionales
que permitan decir si las cosas funcionan o no a grandes rasgos. Por
ejemplo, en el sistema que dice Hernan, si uno toma las posiciones de
hoy mas el cambio en las variables financieras de hoy para mañana,
tiene que ser posible estimar el precio de los trades mañana con muy
poco residual.

Exactamente como funciona eso antes de programarlo? Ni idea! No es
un problema facil en general, y mucho menos "simple". Por eso, me
parece que no queda otra que escribir un test funcional al principio.
Ahora, a medida que se programa todo esto, seguramente van a aparecer
algoritmos o calculos o condiciones especiales que merecen unit tests.
Entonces si, a escribir mas tests se ha dicho.

Tambien me paso que al principio ni siquiera pude escribir tests
funcionales porque no tenia claro, mas alla de los objetivos
generales, que iba a terminar programando. En ese caso, igual me
parece que los tests funcionales son muy valiosos a medida que se
construye el programa.

Un par de comentarios mas. Los tests son parte de la aplicacion, y
hay que escribirlos con el mismo cuidado que se escribe cualquier otra
cosa. Ademas, algo que los tests no garantizan es que el programa que
los pasa sea facil de cambiar. En mi opinion, la flexibilidad es mas
importante que los tests. Los programas que no se pueden cambiar son
como los animales demasiado especializados. Un pequeño cambio en el
medio ambiente, y se extinguen.

Andres.


2009/11/13 Hernan Wilkinson <hernan.w...@gmail.com>:

[Hernan Wilkinson]

2009/11/13 GallegO <fxga...@gmail.com>

Yo me prendería, aunque no se si da para mezclarlo con el día del
Pharo sprint, medio que nos van a mandar a cag.ar

no, vamos a otro laboratorio y listo, si se puede lo hacemos, no tengo drama.
 

No se me ocurre que sería hacer algo groso.

digo, no una pavada, pensar algún ejemplo interesante... yo tengo un par de ejemplos pero son chiquitos, que se yo
Siempre tuve ganas de hacer un juego con tdd pero nunca tuve tiempo. como el pacman, buscaminas, etc.

 

Convengamos que seria algo sobre tdd suponiendo que ya conocemos el
uso de sunit.

si, tal cual
 

[Hernan Wilkinson]

2009/11/13 Andres Valloud <andres....@gmail.com>

Tenia ganas de contestar a este thread...

Para mi, no se pueden escribir todos los tests de antemano, porque eso
implicaria que uno conoce el problema a resolver por completo.  

exacto.
 

jaja, muy bueno. Concuerdo con lo que decís.

Hernan.

[Andres Valloud]

Ojo con el buscaminas que no es trivial para nada... a mi me llevo un
monton de tiempo hacerlo bien!

2009/11/13 Hernan Wilkinson <hernan.w...@gmail.com>:

[Nicolas Chillo]

2009/11/13 Hernan Wilkinson <hernan.w...@gmail.com>

2009/11/13 GallegO <fxga...@gmail.com>

Yo me prendería, aunque no se si da para mezclarlo con el día del
Pharo sprint, medio que nos van a mandar a cag.ar

no, vamos a otro laboratorio y listo, si se puede lo hacemos, no tengo drama.
 

No se me ocurre que sería hacer algo groso.

digo, no una pavada, pensar algún ejemplo interesante... yo tengo un par de ejemplos pero son chiquitos, que se yo
Siempre tuve ganas de hacer un juego con tdd pero nunca tuve tiempo. como el pacman, buscaminas, etc.

Claro.. como nunca tuviste tiempo, dejas que lo hagan tus alumnos, no??? Total ellos si tienen tiempo para hacerlo ;-)

[Guillermo Sapaya]

From: Hernan Wilkinson

> 2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>

>
> pero tdd es acerca de prototipar! es acerca de tener algo funcionando
> rápido... no se cómo están haciendo tdd pero sirve justamente para lo que
> vos estás buscando...

Yo creo que si querés tener algo rápido pero primero tenés que empezar por los tests para tenerlo entonces estamos agregando un delay muy claro para obtenerlo...

> Si solo refactorizas, no tenes que cambiar ningun tests. Los refactorings no
> alteran la ejecuciòn del sistema.
> Si modificas el modelo, por ahí si tenes que modificar tests, dependiendo
> de
> que cambio hayas hecho, pero no es el comun de los casos... de vuelta, no
> entiendo porqué tanto problema por el mantenimiento de los tests, no
> consume
> tanto!

Claro, me refería a grandes refactorings/cambios. No sólo los que te permite hacer el RefactoringBrowser :-)

> Tdd no reemplaza los test funcionales o exploratorios o de ui, etc. que
> deben hacer los testers
> Pero tdd no es solo hacer test unitarios, todo lo contrario y eso es una
> confusión muy grande. Tdd no es bottom-up, es top-down porque justamente es
> exploratorio. Con tdd tambien haces test funcionales, de user story que
> además son los más interesantes y los que más aportan.

Bueno, acá es donde disiento. Creo que si uno tiene los tests funcionales correctos y cubriendo la mayor cantidad de casos de uso que se le ocurra al tester/usuario, no son necesarios los unitTests. Al fin y al cabo, si hay un DNU o lo que fuera también será visto en la corrida de los tests funcionales.
Por otro lado no hace falta TDD para trabajar top-down. Yo siempre trabajé top-down sin usar TDD. Creo que la manera de modelar de un smalltalker debe ser siempre top-down, el prototiping te lleva a eso. Definir la "cáscara" de cada objeto y después meta debugger, inspectores, etc. hasta obtener el resultado esperado, pero sin tener que partir de un test, usando directamente el sistema (ya sea por workspaces o por una UI generada automáticamente para cualquier objeto nuevo que cree).

> Un abrazo,
> Hernan.

Otro,
Guiye

[Gabriel Brunstein]

Actualmente trabajando en XTrade (que tiene una gran bateria de tests) te puedo decir que hacemos cambios/refactorings muy grandes y personalmente me siento mucho más seguro que si no los tuviera y creo que a todos nos pasa lo mismo. Es más, siempre pensamos en nuevas alternativas de cosas a testear para agregar.

Esto no implica que luego no tengamos tests funcionales realizados por especialistas en el dominio. La idea es que, si tuvimos un error, que el mismo no se repita en nuevas versiones (agregamos un test).

Por otro lado, muchos errores (básicos o complejos) suelen filtrarse con estos tests automáticos. Una ventaja de esto es que el tester termina profundizando más y no perdiendo el tiempo en cosas que una máquina puede chequear automáticamente.

2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>

[Hernan Wilkinson]

jaja, no se si tienen tiempo, pero por algo son alumnos no? :-)

2009/11/13 Nicolas Chillo <nch...@gmail.com>

[Hernan Wilkinson]

2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>

From: Hernan Wilkinson

> 2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>
>

> pero tdd es acerca de prototipar! es acerca de tener algo funcionando
> rápido... no se cómo están haciendo tdd pero sirve justamente para lo que
> vos estás buscando...

Yo creo que si querés tener algo rápido pero primero tenés que empezar por los tests para tenerlo entonces estamos agregando un delay muy claro para obtenerlo...

pero no creas que es mucho mas que estar escribiendo y manteniendo en tu cabeza todo lo que haces. Es mucho mejor tirarle ese bardo a la computadora, y por lo tanto te queda la cabeza más libre para pensar mejor...
 

> Si solo refactorizas, no tenes que cambiar ningun tests. Los refactorings no
> alteran la ejecuciòn del sistema.
> Si modificas el modelo, por ahí si tenes que modificar tests, dependiendo
> de
> que cambio hayas hecho, pero no es el comun de los casos... de vuelta, no

> entiendo porqué tanto problema por el mantenimiento de los tests, no
> consume
> tanto!

Claro, me refería a grandes refactorings/cambios. No sólo los que te permite hacer el RefactoringBrowser :-)

> Tdd no reemplaza los test funcionales o exploratorios o de ui, etc. que
> deben hacer los testers
> Pero tdd no es solo hacer test unitarios, todo lo contrario y eso es una
> confusión muy grande. Tdd no es bottom-up, es top-down porque justamente es
> exploratorio. Con tdd tambien haces test funcionales, de user story que
> además son los más interesantes y los que más aportan.

Bueno, acá es donde disiento. Creo que si uno tiene los tests funcionales correctos y cubriendo la mayor cantidad de casos de uso que se le ocurra al tester/usuario, no son necesarios los unitTests. Al fin y al cabo, si hay un DNU o lo que fuera también será visto en la corrida de los tests funcionales.

si, tal cual, pero no te olvides que tdd no es solo sobre testing! la idea es que te ayuda a explorar el dominio, a hacer un modelo menos acoplado, etc. lo de los tests es un agregado nomás.
 

Por otro lado no hace falta TDD para trabajar top-down. Yo siempre trabajé top-down sin usar TDD.

Si, tal cual, no es necesario, pero si haces mal tdd, o sea, te qeudas con test unitarios solamente, entonces haces bottom up y eso esta mal.
 

Creo que la manera de modelar de un smalltalker debe ser siempre top-down, el prototiping te lleva a eso. Definir la "cáscara" de cada objeto y después meta debugger, inspectores, etc. hasta obtener el resultado esperado, pero sin tener que partir de un test, usando directamente el sistema (ya sea por workspaces o por una UI generada automáticamente para cualquier objeto nuevo que cree).

no entiendo por què no a partir de un test? el test está haciendo funcionar el sistema! y lo podes reproducir constantemente, automaticamente, etc. Me parece que solo estàs pensando en test unitarios con tdd y no es así, o como decias Mariano, en test estructurales y no funcionales, no se, me da esa sensación.

Un abrazo
Hernan
 

[Andres Valloud]

> pero no creas que es mucho mas que estar escribiendo y manteniendo en tu
> cabeza todo lo que haces. Es mucho mejor tirarle ese bardo a la computadora,
> y por lo tanto te queda la cabeza más libre para pensar mejor...

Todo depende del tamaño del buffer... hacer I/O con el teclado y el
mouse puede ser tan lento como swappear porque no te alcanza la
memoria. A mi gusto, hay que hacer I/O para leer o escribir cosas muy
pocas veces.

Andres.

[Hernan Wilkinson]

Cuanto es ese buffer? 10, 50, 100 clases? cualquiera sea el numero en definitiva se llena...

2009/11/13 Andres Valloud <andres....@gmail.com>

[Andres Valloud]

Y... depende... seguro que es finito. A mi se me hace dificil
escribir unit tests antes que el codigo cuando el buffer no me alcanza
para implementar lo que hay que testear. En ese caso, prefiero
escribir el codigo primero y despues hacer algun test funcional (o
vice versa).

2009/11/13 Hernan Wilkinson <hernan.w...@gmail.com>:

[Guillermo Sapaya]

Hola Hernán,

> no entiendo por què no a partir de un test? el test está haciendo
> funcionar
> el sistema! y lo podes reproducir constantemente, automaticamente, etc. Me
> parece que solo estàs pensando en test unitarios con tdd y no es así, o
> como
> decias Mariano, en test estructurales y no funcionales, no se, me da esa
> sensación.

Sabés que puede ser lo que decís :-) Quizás nunca entendí bien cómo hacer TDD. Mirá que leí al respecto, inclusive papers de su auténtico creador que para mí es un groso mal :-)
Las veces que intenté me la dí contra la pared, y no soy el único eh! Por eso me parece que TDD tiene algo que ver con como está estructurada tu cabeza :-)
Para mí no se puede hacer en una tarde algo que se le pueda sacar el jugo, eso lleva meses/años, pero bueno, ojalá que si se hace algo pueda ver cómo implementar un sistema desde cero con TDD. Pero me gustaría que sea otro dominio que el de los juegos, ya que decís que es bueno para explorar un dominio (el de los juegos vos ya lo tenés re claro con la cantidad de años que vienen haciéndolo en los TPs :-)). Yo (o cualquiera) te doy un enunciado de un problema que planteamos como capacitación a la gente que entra a trabajar acá y una vez que tenés todo andando te tiro nuevos requerimientos que implican grandes cambios en el modelo.

> Un abrazo
> Hernan

[Hernan Wilkinson]

uh! buenísimo, me encanta! hagamos así

2009/11/13 Guillermo Sapaya <gsa...@infoil.com.ar>

[Alex Schenkman]

¿Podrían hacer disponible el material que surga para los que no podemos asistir?

El problema, la solución, y por sobre todo, las lecciones/conclusiones de algún escéptico convertido. 

La idea de TDD me parece genial, pero nunca sé cómo implementarla desde el principio.

¡Gracias!

PD: El Jueves salió el sol durante 15 minutos. Ayer, estuvo semi-claro toda la mañana. Llevamos más de dos semanas de cielo gris y pesado.

Disculpen, pero aunque no tiene nada que ver, tengo que compartir éstas noticias maravillosas, =)

Estas líneas se escriben desde la latitud N59°. Para tener una idea, Ushuaia está en S55°.

2009/11/13 Hernan Wilkinson <hernan.w...@gmail.com>

[Angel "Java" Lopez]

Hola gente!

No es un juego grafico, pero es un ejemplo clásico que usa la gente para
probar TDD, en el lenguaje original del ejemplo, o en otros:

http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

-----Mensaje original-----
De: clubsm...@googlegroups.com [mailto:clubsm...@googlegroups.com]
En nombre de Andres Valloud
Enviado el: viernes, 13 de noviembre de 2009 15:57
Para: clubsm...@googlegroups.com
Asunto: [clubSmalltalk] Re: DIscusion polemica

[Angel "Java" Lopez]

Hola gente!

 

No segui todo el thread, asi que no se si habían derivado a tests en general o TDD… Pero contesto en el contexto de TDD:

 

Claro, “no se pueden escribir todos los tests de antemano, porque eso implicaría que uno conoce el problema a resolver por completo”.

 

En TDD, no se escriben todos los tests de antemano.

 

Se van escribiendo, de a uno.  Planteando un problema a resolver, y resolviéndolo.

 

Puedo imaginar casos en que es parecido (y en otros, diferente), a la programación exploratoria de Hernan Wilkinson: en vez de probar con el entorno hacer algo, lo probamos por código.

 

No encuentro enlace, pero en el ambiente TDD se ha discutido también algunos temas de este hilo, como: separar entre programación tipo spike, exploratorio, y TDD.

 

Colecciono enlaces sobre TDD que me parecen interesantes en:

http://delicious.com/ajlopez/tdd

 

Algunos enlaces, para aportar ahora:

http://blog.orfjackal.net/2009/10/tdd-is-not-test-first-tdd-is-specify.html

http://works.bepress.com/djanzen/4/

http://www.clariusconsulting.net/blogs/kzu/archive/2009/10/04/172741.aspx del bueno de @kzu uno de los creadores de MoQ The myth that TDD or test-first slows you down is true

 

Otro comentario: podria asimilar un test a un comentario de Smalltalk que muestre como se usa y que se espera de un metodo

 

Otro comentario: es bueno encontrar tests en un proyecto. Los tests quedan practicamente como la especificacion de la funcionalidad esperada de lo que se implemento. Cuando me topo con un proyecto con tests, y un buen code coverage, cualquier actualizacion, modificacion, mejora, refactoreo, incluso portarlo a otra tecnologia, va sobre ruedas. Un proyecto sin tests, aunque sea uno nuestro, tocarlo puede ser un infierno. Michael Feathers tiene una definicion: codigo legacy no es codigo escrito en un lenguaje “obsoleto” o algo asi; no es eso, codigo legacy ES codigo SIN TESTS.

 

Nos leemos!

 

Angel "Java" Lopez

http://www.ajlopez.com/

http://twitter.com/ajlopez

 

De: clubsm...@googlegroups.com [mailto:clubsm...@googlegroups.com] En nombre de Hernan Wilkinson
Enviado el: viernes, 13 de noviembre de 2009 15:56
Para: clubsm...@googlegroups.com
Asunto: [clubSmalltalk] Re: DIscusion polemica

 

 

2009/11/13 Andres Valloud <andres....@gmail.com>

Version: 8.5.425 / Virus Database: 270.14.63/2500 - Release Date: 11/13/09 07:54:00

[Norberto Manzanos]

Muy buena discusión.


Aporto algunas ideas, probablemente muy teñidas de subjetividad, pero que tal vez aún así sirvan para algo.
Trabajar intensivamente con tests fue uno de los cambios más importantes en mi vida como programador, tal vez tan importante como pasar de Pascal a Smalltalk. Siempre me pregunto porqué suceden este tipo de cosas, tratando de centrarme no tanto en el objeto, es decir, la tecnología, si no en el sujeto, es decir, la mente del programador, o sea, la mia. Hernán dice al pasar que aplicar test es tirarle el trabajo a la computadora para poder pensar más en otras cosas y esto me parece que es un aspecto fundamental.
Esto me lleva a una pregunta que se sale totalmente de las cuestiones técnicas, pues al hablar de nuestra cabeza y la forma en que la utilizamos, forzosamente nos salimos de la informática y vamos a un terreno menos explorado, la psicología del programador.
¿Por qué  programamos? (O en todo caso, ¿por qué programo?)
Una primera respuesta sería: por que nos gusta pensar. Es un pensamiento tendiente más a lo analítico-racional que a lo intuitivo, como el del matemático, pero no tanto, y por eso no somos matemáticos. Acaso nuestros estilos, nuestros gustos como programadores puedan definirse por el grado de combinación entre el pensamiento deductivo y el intuitivo. Pero más allá de esta difícil cuestión, lo que quiero destacar es que ese gusto por pensar tiene que tener ciertas características para que no sea simplemente una patología: es posible pensar mucho y muy analíticamente sin llegar a ninguna parte. Obviamente, nuestro límite más grande es que la programación genera un producto sujeto a una validación inmediata: el programa tiene que funcionar, aquí y ahora. Pero volviendo a lo que es estrictamente la actividad de programar, nuestro aliado más grande es una vieja característica de la naturaleza humana (y de la naturaleza en general, por qué no) que es la economía. Economía en sentido amplio, no economía monetaria: lo que a veces se llama economía de esfuerzo. Lo que nos maravilla de la tan mentada elegancia matemática no es otra cosa que la economía.
Cada vez que podemos olvidarnos de que abajo de nuestro Smalltalk hay un sistema operativo, cada vez que delegamos una responsabilidad en otros objetos, cada vez que confiamos en un framework, estamos liberando memoria de nuestras mentes que en lugar de ocuparse de asuntos de otros, se puede ocupar de los propios.
Se podría definir la actividad de programar como tratar de resolver cuestiones cada vez más complejas mediante soluciones cada vez más simples. Llevándolo al extremo, cuando la economía ha logrado una simplificación total, no hace falta programar. Es el caso de como laburan muchos programadores actualmente, pegando cosas, configurando, llenando especificaciones, pero sin escribir una línea de código, o muy pocas. Es una paradoja para pensarla aparte. Pero esta paradoja tal vez nos enseñe algo: que a veces también queremos ponerle un límite a la actividad economizadora, pues nos hace ganar mucho, pero también nos puede hacer perder algo.

En mis primeros tiempos como programador encontraba mucho placer en tener la totalidad de un sistema en la cabeza: cada variable, cada procedimiento (estoy hablando de Pascal). Me gustaba incluso leer un programa de cabo a rabo y tratar de mantener las bifurcaciones posibles en la  cabeza, para ver si el sistema soportaba todos los acontecimientos posibles.
No se si esta es una conducta normal en un programador incipiente, si es propia de la juventud, o que, pero hace rato que encuentro placer en algo totalmente opuesto: que lo que hago descanse sobre bases que no hay que conocer en detalle, o al menos, si alguna vez conocí los detalles, que haya un punto en que es posible olvidarlos.

Precisamente, el trabajo a partir de tests permite, si no olvidar los detalles, poder hacer funcionar la mente de tal forma que los detalles puedan ser olvidados temporariamente, pero que ante la necesidad de conocerlos, poder recuperarlos, hacer un "load", tal vez mandando a otra página los aspectos de más alto nivel, trabajar sobre esos detalles, para finalmente volver a liberar la mente y seguir adelante con el objetivo inicial.
Cada vez que descubro que por haber cambiado un detalle se produce un impacto no deseado y que este descubrimiento no fue producto de tener todo el código en mi cabeza, si no una simple luz roja me maravillo:  los tests me están ayudando a economizar, no el código, si no mi propia actividad mental.

Creo que las falencias achacables al trabajo con test no tienen que ver con la idea subyacente a esta metolodogía, si no más bien con las limitaciones que tienen las herramientas que utilizamos.
Señalo sólo una, para no hacerla tan larga.
Dado que los tests son una especie de registro de la actividad del sujeto sobre un determinado dominio, es imprescindible que ese registro tenga no sólo un ordenamiento temporal, si no también un ordenamiento lógico, un ordenamiento de los más simple a lo más complejo.
Supongamos el test más boludo del mundo: asignación y verificación de la asignación, es decir, un setter y luego un getter que devuelva el objeto seteado. Si bien hay casos en que esto no es trivial, en la mayoría los casos lo es. No obstante, me ha pasado que el browser se me tare y me modifique las variables asignadas. Es claro que si este test falla, todos los demás deberían fallar y todos estos fallos son triviales, pues dependen de un único fallo básico. Con las herramientas que utilizamos normalmente no hay forma de detectar que es ese test básico el que está fallando.
Yo uso un método muy pedorro que no recomiendo a nadie, pero que a mi me sirve: numero los nombres de los métodos tratanto de mantener así el órden lógico. A la espera de algo mejor.

Despues de tanto bla bla, un poco de código.
Hace un tiempo hice una ampliación del TestRunner de Squeak para suplir alguna de las falencias de las herramientas de test. Es algo bastante primitivo porque para hacerlo bien hay que modelar muchas cosas que no están modeladas en Squeak (las categorías de clases y métodos, por ejemplo) .
Este es el script de instalación (tiene que estar el último Installer cargado)

| url |
url:=url:= 'www.squeaksource.com'.
(HTTPSocket httpGet: 'http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressBarMorph.st') readStream fileIn.
(HTTPSocket httpGet: 'http://swikicaicyt.homeip.net/WebOpus/uploads/ProgressMorph.st') readStream fileIn.
(Installer monticello http: url )  project: 'CoverageTestCase';
    install: 'CoverageTestCase'.

Luego hay que hacer
TestFanRunner initialize.
TestFanRunner open.
(Para que aparezcan los tests propios tiene que ser subclases de CoverageTestCase)

Está también en la página nuestra (http://www.caicyt.gov.ar/letodoc/paquetes-publicados) pero aún no hay ninguna documentación.

Saludos
Norberto

[Guillermo Schwarz]

Norberto,

Me leiste la mente.

Comento algunos insights que encontré absurdos:

1. "es posible pensar mucho y muy analíticamente sin llegar a ninguna parte". Es posible llegar a contradicciones o contradicciones aparentes. Si llegas a alguna parte o no, es cosa de prueba y error (el método científico). La base de la ciencia es el descubrimiento y el descubriento es por definición impredecible. Eso de "sin llegar a ninguna parte" es sólo un punto de vista. Otra persona podría decir lo contrario ante la misma situación.

2. "[Programar] Es un pensamiento tendiente más a lo analítico-racional que a lo intuitivo, como el del matemático, pero no tanto, y por eso no somos matemáticos." Discrepo profundamente de esa frase. Me inicié en el mundo de la programación programando juegos y los mejores juegos eran los que usaban fórmulas matemáticas. No sólo andaban más rápido, sino que los resultados eran mejores. Programar al fin y al cabo no es más que realizar transformaciones algebraicas. Quienes no lo hacen así, escriben tremendos enredos que funcionan mal y son inmodificables (frágiles). Peter Naur sostiene que programar es equivalente a la construcción de teorías.

3. "Llevándolo al extremo, cuando la economía ha logrado una simplificación total, no hace falta programar." Amén. Suena absurdo, pero históricamente ha ocurrido lo mismo en casi todos los ámbitos de la actividad humana. Por eso hoy en día no existen escribas ni herreros. En el ámbito de la programación, las especificaciones serán ejecutables. Es el equivalente a decir que habrá un programa universal que resolverá todo, sólo necesitará conocer las especificaciones y ejecutarlas directamente. Es interesante, pero más interesante seŕa cuando la Economía como disciplina se encuentre resuelta. Entonces se acabará la escasez, y en un mundo sin escasez los precios tienden a cero. Es un poco lo que estamos viviendo, excepto para bienes que no pueden ser creados, como los bienes inmuebles que se disparan de precio porque el terreno no puede ser creado.

4. " los tests me están ayudando a economizar, no el código, si no mi propia actividad mental." Llevándolo al extremo, se podría pensar que un módulo genera tests que son importantes para lograr un resultado y otro módulo genera el programa que pasa esos tests. Ambas actividades son automatizables. El primer corolario es que el programador dejará de ser necesario y el segundo corolario es que los sistemas que podremos construir serán cada vez más grandes. Diría que el límite hoy en día es la imaginación del cliente y no la capacidad de programar el sistema (a menos que estés aprendiendo a programar).

5. "me ha pasado que el browser se me tare y me modifique las variables asignadas" Suena remal. Yo escribiría el browser de nuevo usando tests para todo, o lo instrumentaría para ver porqué se tara. Si estás construyendo un edificio de piezas lego, primero asegúrate que las piezas estén bien. Si ignoras los defectos de las piezas y luego construyes un artefacto para controlar la caida del edificio, puede ser mucho más esfuerzo y no lograr los resultados esperados. Al fin y al cabo lo importante es tener claro los objetivos de largo plazo y tener un plan coherente que muestre la luz al final del túnel.

Saludos,
Guillermo.

2009/11/15 Norberto Manzanos <nman...@gmail.com>

--
Saludos cordiales,

Guillermo Schwarz
Sun Certified Enterprise Architect

[Hernan Wilkinson]

Que haces Alex!!! 

 me imagino lo que se debe extrañar el sol!!! 

 Vamos a hacer todo lo posible para que lo que hagamos se pueda publicar de la mejor manera posible.

 Venite para Argentina!!! jaja.

 Un abrazo,

 Hernan.

2009/11/14 Alex Schenkman <al...@schenkman.info>

[Sergio Del Franco]

2009/11/16 Guillermo Schwarz <guillerm...@gmail.com>:
[...]

> Por eso hoy en día no existen escribas

[...]

Existen. Pero se los llama "piratas" y se los criminaliza.

--
Sergio.

[Guillermo Schwarz]

Sergio,

¿Dices que son piratas porque los escribas copian textual?

Yo les doy un poquito más de crédito. Para nosotros escribir es un chiste, ya que la escritura es onomatopéyica (como suena), si tuviéramos que escribir ideas con monos (dibujos) para que otros lo interpreten, nadie menor de 40 años sabría leer ni escribir.

Saludos,
Guillermo.

[Diego Gomez Deck]

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

[Guillermo Schwarz]

Hola Diego,

TDD es una filosofía mucho más profunda que sólo hacer tests al código fuente. Se puede aplicar a los diseños de software y a cualquier actividad humana en que los resultados puedan fallar. Por ejemplo, si creas un diseño de una planta de energía solar, ¿cómo pruebo que el diseño funciona? La respuesta es simple: Creo un prototipo pequeño que muestra que funciona. Muchas de las prácticas de XP se basan en el mismo principio.

Y para complementar las ventajas que mencionaste, creo que faltaron las desventajas:

1. Falta de confianza de parte de aquellos que nunca lo han practicado (siempre existe un "caso" imaginario en que piensan que el TDD no aplica).
2. Por definición los clientes (incluyendo a los usuarios) no utilizan TDD (aunque puede que en sus áreas de expertise sí apliquen un concepto equivalente). Un médico no te pregunta si quieres que se lave las manos antes de operarte, ni tampoco le haría caso al director del hospital si le dice que no se lave las manos para ahorrar tiempo. De la misma manera, los profesionales del desarrollo de software no deberían preguntar si deben hacer tests.
3. Requiere de más esfuerzo intelectual usar TDD.
4. Los proyectos terminan antes, ya que gran parte del tiempo en los proyectos sin TDD se pierde en estabilizar código que no funciona integradamente (los típicos problemas de integración). Con TDD, necesariamente todo el código está probado, de modo que muchos menos problemas se presentan, ya que al momento de introducir un problema se disparan todas las alarmas. Esto tiene como consecuencia que los empleados cambian de trabajo con más regularidad que el resto, lo que no es necesariamente bueno para los empleados.

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?

Saludos,
Guillermo.

2009/11/22 Diego Gomez Deck <DiegoGo...@consultar.com>

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

[Gabriel Brunstein]

2009/11/22 Guillermo Schwarz <guillerm...@gmail.com>

...

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.

[Guillermo Schwarz]

Exacto. Deberíamos hacerlo para ser profesionales (cumplir con plazos 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áctica 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 <gab...@gmail.com>

[Abel Armoa]

Que tal Guillermo:

Yo creo que hay muchísimos profesionales que hacen las cosas bien simplemente 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 depender de cuánto nos pagan por el.

Por este motivo no creo que el interés de los agentes económicos pueda influir en algo en que TDD se siga utilizando o sea olvidado.

Saludos,
Abel Armoa

2009/11/22 Guillermo Schwarz <guillerm...@gmail.com>

[Guillermo Schwarz]

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

[Mariano Abel Coca]

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.

En los 60's no existía ni Smalltalk ni SUnit. :)


Saludos,

Mariano.

[dcoro...@gmail.com]

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 <DiegoGomezD...@consultar.com>
wrote:

[Guillermo Schwarz]

Exacto, ni Smalltalk ni SUnit, sólo Lisp y COBOL. Sin embargo, como práctica de ingeniería, las pruebas unitarias si existían y tuvieron su periodo de auge, en disciplinas más orientadas al fierro.

¿Porqué cayeron en el olvido? No sé. Pero supongo que no se hizo marketing del hecho de que se estaba usando pruebas unitarias, de modo que cualquier éxito se atribuyó a otras cosas.

Para que no vuelva a ocurrir lo mismo, a cualquier proyecto que se aplique pruebas unitarias, se debería promocionar como tal, de modo que cualquier éxito logrado los clientes lo asoscien a que se hizo pruebas unitarias.

Te pongo un ejemplo: En JP Morgan, los grandes jefes están convencidos de la necesidad de hacer pruebas unitarias, pero los programadores y los jefes de proyecto no están convencidos.

Saludos,
Guillermo.

2009/11/23 Mariano Abel Coca <mariano...@gmail.com>

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

En los 60's no existía ni Smalltalk ni SUnit. :)


Saludos,

Mariano.

[Andres Valloud]

Ehhh... acerca de JP Morgan, por lo menos en mi experiencia con
Kapital, basicamente todos estan convencidos de que la aplicacion
tiene que pasar los tests. Pero bueno, Kapital es solo una aplicacion
adentro de JP Morgan. Me parece que depende mas del proyecto en
particular que del lugar donde se encuentre.

Andres.

2009/11/23 Guillermo Schwarz <guillerm...@gmail.com>: