Consulta sobre TDD ( Test Driven Development )
74 views
Skip to first unread message
Jonathan Vila Lopez
Sep 18, 2009, 4:01:33 AM9/18/09
to agile...@googlegroups.com
Hola a todos.
Estos días he estado leyendo un poquito sobre TDD y lo he visto muy interesante ......... pero no veo la forma práctica de abordarlo.
El principio básico, sin no he entendido mal, reside en desarrollar los casos de test antes de desarrollar el software...... pero, como puedo probar algo que no está desarrollado ? creo el método del test pero luego que hago dentro ? si aún no tengo las clases creadas y con los métodos implementados como puedo controlar si tal operación da el resultado esperado o no ?
Seguramente algo he entendido mal........
Saludos.
Jonathan V.
-----------------------------------------------
Slitzweitz !!!!!!
Estos días he estado leyendo un poquito sobre TDD y lo he visto muy interesante ......... pero no veo la forma práctica de abordarlo.
El principio básico, sin no he entendido mal, reside en desarrollar los casos de test antes de desarrollar el software...... pero, como puedo probar algo que no está desarrollado ? creo el método del test pero luego que hago dentro ? si aún no tengo las clases creadas y con los métodos implementados como puedo controlar si tal operación da el resultado esperado o no ?
Seguramente algo he entendido mal........
Saludos.
Jonathan V.
-----------------------------------------------
Slitzweitz !!!!!!
On Fri, Sep 18, 2009 at 9:54 AM, José Manuel Beas <jose....@gmail.com> wrote:
¿Cómo propones incluir a esos buenos practicantes pero que son reacios
a incorporarse a la comunidad?
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.blogspot.com
2009/9/18 Xavi Gost <xav...@gmail.com>:
>
> Me parece interesante y .. como van unos años por delante pues....
>
> I feel majority of the Agile community has got into a “preaching mode”
> and very few people are actually building their own products (eating
> their own dog food.) This attitude attracts a certain kind of people
> to the conference and I’m quite skeptical to find innovative new ideas
> in this crowd. With so much noise its also very easy to miss some weak
> signals which have potential.
>
> I do know a few people who are doing some really interesting stuff
> (they are turned off by the Agile brand and generally don’t hang
> around in these circles). Personally I want us, as a community, to be
> more inclusive of these people.
>
> Xavier Gost
>
> >
>
José Manuel Beas
Sep 18, 2009, 4:07:23 AM9/18/09
to agile...@googlegroups.com
El ciclo de TDD consiste en lo siguiente:
1. Escribes un test (que falla, porque al principio puede que ni compile)
2. Sólo escribes el código necesario para que el test (y todos los
demás que ya tuvieras) se ponga "en verde"
3. Refactorizas, es decir, cambias código para mejorar el diseño, la
legibilidad, etc, pero SIEMPRE manteniendote "en verde"
4. Volver al punto 1
Hay también una lista especializada en TDD en español, por si te interesa:
http://groups.google.com/group/tddev-sp
No te asustes por el spam que hay en esa lista, es que el verano ha
hecho estragos. :-)
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
1. Escribes un test (que falla, porque al principio puede que ni compile)
2. Sólo escribes el código necesario para que el test (y todos los
demás que ya tuvieras) se ponga "en verde"
3. Refactorizas, es decir, cambias código para mejorar el diseño, la
legibilidad, etc, pero SIEMPRE manteniendote "en verde"
4. Volver al punto 1
Hay también una lista especializada en TDD en español, por si te interesa:
http://groups.google.com/group/tddev-sp
No te asustes por el spam que hay en esa lista, es que el verano ha
hecho estragos. :-)
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
German DZ
Sep 18, 2009, 4:11:52 AM9/18/09
to agile...@googlegroups.com
Estás en el punto en que todos nos encontramos en algún momento, para ser sinceros, digamos que no es sencillo. Recibirás 1001 consejos y seguramente todos muy buenos, pero es casi como para los que debieron pasar de programar estructurado a OO, en un momento tu cerebro hace un click y todo se ve más claro.
TDD y muchas otras prácticas se han desarrollado muchísimo en los últimos años y hoy en día las discusiones están en un nivel de detalle muy fino, intenta conseguir información introductoria y aunque sea antigua, para poder captar la esencia y no perderte en el océano de detalles.
TDD y muchas otras prácticas se han desarrollado muchísimo en los últimos años y hoy en día las discusiones están en un nivel de detalle muy fino, intenta conseguir información introductoria y aunque sea antigua, para poder captar la esencia y no perderte en el océano de detalles.
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>
Hola a todos.
jcesarperez
Sep 18, 2009, 4:17:27 AM9/18/09
to agile-spain
Antes de escribir el test debes definir el interface (en Java) de lo
que quieres probar.
Usándolo como una referencia ya puedes escribir el método de test. Es
aquí donde esta la potencia del TDD, te ayuda a pensar en el interface
de la clase y cómo funciona.
Obviamente fallará con un nullpointerexception. Cuando tengas la clase
implementada, lo instancias y asocias a la referencia antes creada en
el método setUp del test (en Junit).
Como podrás imaginar el TDD está bien para interfaces complejas que
necesitan madurarse mentalmente o las interfaces de tus métodos
service (donde tienes la lógica de la app). Pero no es necesario usar
TDD para todas tus clases!
Espero haberte ayudado...
Un saludo,
Julio.
On 18 sep, 10:01, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Hola a todos.
>
> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> interesante ......... pero no veo la forma práctica de abordarlo.
>
> El principio básico, sin no he entendido mal, reside en desarrollar los
> casos de test antes de desarrollar el software...... pero, como puedo probar
> algo que no está desarrollado ? creo el método del test pero luego que hago
> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> como puedo controlar si tal operación da el resultado esperado o no ?
>
> Seguramente algo he entendido mal........
>
> Saludos.
> Jonathan V.
>
> -----------------------------------------------
> Slitzweitz !!!!!!
>
que quieres probar.
Usándolo como una referencia ya puedes escribir el método de test. Es
aquí donde esta la potencia del TDD, te ayuda a pensar en el interface
de la clase y cómo funciona.
Obviamente fallará con un nullpointerexception. Cuando tengas la clase
implementada, lo instancias y asocias a la referencia antes creada en
el método setUp del test (en Junit).
Como podrás imaginar el TDD está bien para interfaces complejas que
necesitan madurarse mentalmente o las interfaces de tus métodos
service (donde tienes la lógica de la app). Pero no es necesario usar
TDD para todas tus clases!
Espero haberte ayudado...
Un saludo,
Julio.
On 18 sep, 10:01, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Hola a todos.
>
> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> interesante ......... pero no veo la forma práctica de abordarlo.
>
> El principio básico, sin no he entendido mal, reside en desarrollar los
> casos de test antes de desarrollar el software...... pero, como puedo probar
> algo que no está desarrollado ? creo el método del test pero luego que hago
> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> como puedo controlar si tal operación da el resultado esperado o no ?
>
> Seguramente algo he entendido mal........
>
> Saludos.
> Jonathan V.
>
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> On Fri, Sep 18, 2009 at 9:54 AM, José Manuel Beas <jose.m.b...@gmail.com>wrote:
>
>
>
> > ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> > a incorporarse a la comunidad?
>
> > Un saludo,
> > Jose Manuel Beas
>
> >http://www.agile-spain.com
> >http://jmbeas.blogspot.com
>
> > 2009/9/18 Xavi Gost <xavi...@gmail.com>:
>
>
>
> > ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> > a incorporarse a la comunidad?
>
> > Un saludo,
> > Jose Manuel Beas
>
> >http://www.agile-spain.com
> >http://jmbeas.blogspot.com
>
José Manuel Beas
Sep 18, 2009, 4:17:37 AM9/18/09
to agile...@googlegroups.com
¿Alguien puede aconsejar una buena lectura introductoria sobre TDD?
Yo propongo el libro de Beck, claro.
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
¿Alguien ha leído algo mejor?
2009/9/18 German DZ <ge...@ndz.com.ar>:
Yo propongo el libro de Beck, claro.
http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
¿Alguien ha leído algo mejor?
2009/9/18 German DZ <ge...@ndz.com.ar>:
Juan Carlos Quijano Abad
Sep 18, 2009, 4:21:25 AM9/18/09
to agile...@googlegroups.com
Y pregunto yo... ¿compensa?
No es por hacer la puñeta pero cada vez que me pongo a estudiar una nueva tecnología es lo primero que me pregunto.. en algunos casos -como en POO- no hay duda, en otro - como MVC - no lo he visto claro y lo he dejado atrás.
¿El TDD compensa? Soy todo oidos de lego a las opiniones. :)
--
Un saludo
Juan Quijano
No es por hacer la puñeta pero cada vez que me pongo a estudiar una nueva tecnología es lo primero que me pregunto.. en algunos casos -como en POO- no hay duda, en otro - como MVC - no lo he visto claro y lo he dejado atrás.
¿El TDD compensa? Soy todo oidos de lego a las opiniones. :)
--
Un saludo
Juan Quijano
jcesarperez
Sep 18, 2009, 4:22:21 AM9/18/09
to agile-spain
Uno muy bueno sobre testing es el de Pragmatic Programmer ->
http://www.amazon.com/Pragmatic-Unit-Testing-Java-JUnit/dp/0974514012
Aunque es más de testing en general (diseño, mocking, buenas
practicas, etc) que de TDD (con D de desarrollo, que no diseño).
On 18 sep, 10:17, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> ¿Alguien puede aconsejar una buena lectura introductoria sobre TDD?
>
> Yo propongo el libro de Beck, claro.http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
http://www.amazon.com/Pragmatic-Unit-Testing-Java-JUnit/dp/0974514012
Aunque es más de testing en general (diseño, mocking, buenas
practicas, etc) que de TDD (con D de desarrollo, que no diseño).
On 18 sep, 10:17, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> ¿Alguien puede aconsejar una buena lectura introductoria sobre TDD?
>
>
> ¿Alguien ha leído algo mejor?
>
> Un saludo,
> Jose Manuel Beas
>
> http://www.agile-spain.comhttp://jmbeas.blogspot.com
>
> 2009/9/18 German DZ <g...@ndz.com.ar>:
> ¿Alguien ha leído algo mejor?
>
> Un saludo,
> Jose Manuel Beas
>
> http://www.agile-spain.comhttp://jmbeas.blogspot.com
>
>
> > Estás en el punto en que todos nos encontramos en algún momento, para ser
> > sinceros, digamos que no es sencillo. Recibirás 1001 consejos y seguramente
> > todos muy buenos, pero es casi como para los que debieron pasar de programar
> > estructurado a OO, en un momento tu cerebro hace un click y todo se ve más
> > claro.
>
> > TDD y muchas otras prácticas se han desarrollado muchísimo en los últimos
> > años y hoy en día las discusiones están en un nivel de detalle muy fino,
> > intenta conseguir información introductoria y aunque sea antigua, para poder
> > captar la esencia y no perderte en el océano de detalles.
>
> > 2009/9/18 Jonathan Vila Lopez <jonathan.v...@gmail.com>
> > Estás en el punto en que todos nos encontramos en algún momento, para ser
> > sinceros, digamos que no es sencillo. Recibirás 1001 consejos y seguramente
> > todos muy buenos, pero es casi como para los que debieron pasar de programar
> > estructurado a OO, en un momento tu cerebro hace un click y todo se ve más
> > claro.
>
> > TDD y muchas otras prácticas se han desarrollado muchísimo en los últimos
> > años y hoy en día las discusiones están en un nivel de detalle muy fino,
> > intenta conseguir información introductoria y aunque sea antigua, para poder
> > captar la esencia y no perderte en el océano de detalles.
>
>
> >> Hola a todos.
>
> >> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> >> interesante ......... pero no veo la forma práctica de abordarlo.
>
> >> El principio básico, sin no he entendido mal, reside en desarrollar los
> >> casos de test antes de desarrollar el software...... pero, como puedo probar
> >> algo que no está desarrollado ? creo el método del test pero luego que hago
> >> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> >> como puedo controlar si tal operación da el resultado esperado o no ?
>
> >> Seguramente algo he entendido mal........
>
> >> Saludos.
> >> Jonathan V.
>
> >> -----------------------------------------------
> >> Slitzweitz !!!!!!
>
> >> On Fri, Sep 18, 2009 at 9:54 AM, José Manuel Beas <jose.m.b...@gmail.com>
> >> Hola a todos.
>
> >> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> >> interesante ......... pero no veo la forma práctica de abordarlo.
>
> >> El principio básico, sin no he entendido mal, reside en desarrollar los
> >> casos de test antes de desarrollar el software...... pero, como puedo probar
> >> algo que no está desarrollado ? creo el método del test pero luego que hago
> >> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> >> como puedo controlar si tal operación da el resultado esperado o no ?
>
> >> Seguramente algo he entendido mal........
>
> >> Saludos.
> >> Jonathan V.
>
> >> -----------------------------------------------
> >> Slitzweitz !!!!!!
>
> >> wrote:
>
> >>> ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> >>> a incorporarse a la comunidad?
>
> >>> Un saludo,
> >>> Jose Manuel Beas
>
> >>>http://www.agile-spain.com
> >>>http://jmbeas.blogspot.com
>
> >>> 2009/9/18 Xavi Gost <xavi...@gmail.com>:
>
> >>> ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> >>> a incorporarse a la comunidad?
>
> >>> Un saludo,
> >>> Jose Manuel Beas
>
> >>>http://www.agile-spain.com
> >>>http://jmbeas.blogspot.com
>
José Manuel Beas
Sep 18, 2009, 4:24:12 AM9/18/09
to agile...@googlegroups.com
Jonathan Vila Lopez
Sep 18, 2009, 4:37:37 AM9/18/09
to agile...@googlegroups.com
Muchas gracias a todos, sois la caña.........
La verdad que todo este mundo del Agile me "abruma" un poco por mi falta de conocimiento, pero gracias a vuestras aportaciones cada vez veo más luz al final del tunel.
La verdad que todo este mundo del Agile me "abruma" un poco por mi falta de conocimiento, pero gracias a vuestras aportaciones cada vez veo más luz al final del tunel.
Harald
Sep 18, 2009, 4:47:00 AM9/18/09
to agile-spain
Sois muy rápidos. En cuanto tengo una respuesta redactada, ya hay 4-5
respuesta. Lo que escribí era :-):
Hay gente que dice que una batería de casos pruebas que describe un
sistema implementado, vale más que el sistema implementado. El
razonamiento es que con la batería de tests puedes volver a construir
el sistema las veces que quieras, mientras con el sistema implementado
no llegas muy lejos, sin reingenería del código y interpretación del
resultado (siempre con la duda si el resultado es el deseado).
Por mi parte no hay duda que es el camino a seguir porque aumenta la
probabilidad que el resultado final corresponde a lo que quiere el
cliente. Otra cosa es que sea difícil de aplicar por el argumento
principal que TDD invierte el ciclo "habitual" en muchos equipos de
trabajo y requiere mucha "gestión del cambio".
Teóricamente, si describes lo que debe hacer tu aplicación en términos
de use-cases, user-stories con el nivel de detalle que te recomiendan
los cracks, el paso de convertir esta descripción en una batería de
casos de pruebas tampoco debe ser traumático.
Prácticamente (por lo menos en los proyectos con conozco) cuesta mucho
o no funciona (y por tanto, salvo en un caso, no hemos logrado aún de
aplicarlo), principalmente porque el cliente no es capaz de definir de
forma detallada sus requerimientos sin ver un prototipo o la solución
implementada o porque falla el equipo dada la tendencia de preferir
"programar" en vez de "escribir".
Ambos aspectos, en mi opinión, pueden mejorar bastante utilizando
SCRUM u otras metodologías con iteraciones cortas y implicación del
usuario / cliente, aunque, como hemos visto hay también problemas de
adaptación de las metodos agiles en general.
Vamos, tenemos recorrido por delante, pero esto es lo que lo hace
interesante :-)
¿Cual es vuestra experiencia con la aplicación real de TDD? ¿Cuales
son los factores de éxito / fracaso?
Un saludo,
Harald
respuesta. Lo que escribí era :-):
Hay gente que dice que una batería de casos pruebas que describe un
sistema implementado, vale más que el sistema implementado. El
razonamiento es que con la batería de tests puedes volver a construir
el sistema las veces que quieras, mientras con el sistema implementado
no llegas muy lejos, sin reingenería del código y interpretación del
resultado (siempre con la duda si el resultado es el deseado).
Por mi parte no hay duda que es el camino a seguir porque aumenta la
probabilidad que el resultado final corresponde a lo que quiere el
cliente. Otra cosa es que sea difícil de aplicar por el argumento
principal que TDD invierte el ciclo "habitual" en muchos equipos de
trabajo y requiere mucha "gestión del cambio".
Teóricamente, si describes lo que debe hacer tu aplicación en términos
de use-cases, user-stories con el nivel de detalle que te recomiendan
los cracks, el paso de convertir esta descripción en una batería de
casos de pruebas tampoco debe ser traumático.
Prácticamente (por lo menos en los proyectos con conozco) cuesta mucho
o no funciona (y por tanto, salvo en un caso, no hemos logrado aún de
aplicarlo), principalmente porque el cliente no es capaz de definir de
forma detallada sus requerimientos sin ver un prototipo o la solución
implementada o porque falla el equipo dada la tendencia de preferir
"programar" en vez de "escribir".
Ambos aspectos, en mi opinión, pueden mejorar bastante utilizando
SCRUM u otras metodologías con iteraciones cortas y implicación del
usuario / cliente, aunque, como hemos visto hay también problemas de
adaptación de las metodos agiles en general.
Vamos, tenemos recorrido por delante, pero esto es lo que lo hace
interesante :-)
¿Cual es vuestra experiencia con la aplicación real de TDD? ¿Cuales
son los factores de éxito / fracaso?
Un saludo,
Harald
Jonathan Vila Lopez
Sep 18, 2009, 4:57:01 AM9/18/09
to agile...@googlegroups.com
A lo que aporta Harald, puedo añadir que para los prototipos nosotros hemos estado usando algunas herramientas muy útiles con las que hemos conseguido un prototipo "funcional" sin necesitar de codificar........... Serena Prototype Composer es una de esas herramientas, pero hay más ( si necesitais os paso nombres ).
Con ello generamos un prototipo que el cliente puede "tocar" y que nos aporta un feedback sobre sus requerimientos dinamicos...........ha sido muy util.
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
Con ello generamos un prototipo que el cliente puede "tocar" y que nos aporta un feedback sobre sus requerimientos dinamicos...........ha sido muy util.
Saludos.
-----------------------------------------------
Slitzweitz !!!!!!
2009/9/18 Harald <harr...@gmail.com>
José Manuel Beas
Sep 18, 2009, 5:12:58 AM9/18/09
to agile...@googlegroups.com
Hay varios niveles de TDD: a nivel de pruebas unitarias hasta hablar
de pruebas de aceptación (aquí algunos hablan de ATDD por si lo veis
escrito por ahi). El ciclo es el mismo y los beneficios también los
mismos. La idea final es no escribir más código del necesario.
Parece que vosotros habláis más de pruebas de aceptación. Dependiendo
de vuestro entorno tecnológico, hay decenas de herramientas para
automatizar las pruebas (de aceptación). Yo me atrevo a recomendaros
Concordion [1] porque es bastante aséptico: escribes en html y luego
lo instrumentas (escribes código de "pegamento" para hablar con tu
sistema, que puede ser una aplicación web, un webservice, ... lo que
quieras). Pero esto queda ya un poco off-topic. :-)
[1] http://www.concordion.org
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
de pruebas de aceptación (aquí algunos hablan de ATDD por si lo veis
escrito por ahi). El ciclo es el mismo y los beneficios también los
mismos. La idea final es no escribir más código del necesario.
Parece que vosotros habláis más de pruebas de aceptación. Dependiendo
de vuestro entorno tecnológico, hay decenas de herramientas para
automatizar las pruebas (de aceptación). Yo me atrevo a recomendaros
Concordion [1] porque es bastante aséptico: escribes en html y luego
lo instrumentas (escribes código de "pegamento" para hablar con tu
sistema, que puede ser una aplicación web, un webservice, ... lo que
quieras). Pero esto queda ya un poco off-topic. :-)
[1] http://www.concordion.org
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
Julio César Pérez Arques
Sep 18, 2009, 5:19:12 AM9/18/09
to agile...@googlegroups.com
@Jonathan: puedes dar algun nombre más y contarnos un poco cómo funcionan esas herramientas?
¿Son programáticas o tipo grabadora, como selenium IDE?
¿Son para aplicaciones web, escritorio o servicios web?
¿Los valores a probar los codificas a pelo o se leen desde BBDD o ficheros de propiedades?
Gracias por adelantado.
@Harald: yo por mi parte lo que es tdd hago muy poquito, como comentaba antes sólo cuando no tengo muy claro el interface de una clase.
Luego otra cosa que no tengo muy clara es cómo hacer TDD con pruebas de aceptación (pej pruebas funcionales web), yo tenía entendido que TDD era con pruebas unitarias o de integración.
Un saludo.
Julio.
¿Son programáticas o tipo grabadora, como selenium IDE?
¿Son para aplicaciones web, escritorio o servicios web?
¿Los valores a probar los codificas a pelo o se leen desde BBDD o ficheros de propiedades?
Gracias por adelantado.
@Harald: yo por mi parte lo que es tdd hago muy poquito, como comentaba antes sólo cuando no tengo muy claro el interface de una clase.
Luego otra cosa que no tengo muy clara es cómo hacer TDD con pruebas de aceptación (pej pruebas funcionales web), yo tenía entendido que TDD era con pruebas unitarias o de integración.
Un saludo.
Julio.
Abel Muiño
Sep 18, 2009, 5:25:50 AM9/18/09
to agile...@googlegroups.com
Hola Juan,
Sin tener mucha experiencia, lo hemos utilizado para construir webservices.
Partiendo de la interfaz (wsdl) generamos el esqueleto del webservice y de la implementación (esto es automático) y diseñamos las pruebas (que fallan, ya que el esqueleto no hace nada).
Después se implementa la parte servidora hasta que todas las pruebas pasan.
Esto es muy fácil porque el objetivo es implementar un sistema informático... lo veo mucho más dificil para probar una interfaz web antes de haberla hecho (aunque el patrón PageObjects permite abstraerse del html).
En la práctica, nosotros hacemos poco TDD y más testing "de regresión" (de alguna forma sabemos que algo funciona y añadimos un test que se rompa si eso cambia) o "de confirmación" (cuando algo no está claro -ejemplo real "en este caso ¿el webservice devuelve un array vacío o null?"-, se hace un test y el resultado se pasa a documentación).
No es lo mejor, pero es una solución "pragmática" y fácil de incorporar a nuestro equipo (más que un cambio total en la forma de desarrollar software). Incrementalmente, intentamos añadir algo de TDD (aunque suelen ser pocos tests y casi todos para probar el "exito con datos correctos" y no los caminos laterales).
Un saludo!
--
Abel Muiño - http://ramblingabout.wordpress.com/
2009/9/18 Juan Carlos Quijano Abad <juancarl...@gmail.com>
Y pregunto yo... ¿compensa?
No es por hacer la puñeta pero cada vez que me pongo a estudiar una nueva tecnología es lo primero que me pregunto.. en algunos casos -como en POO- no hay duda, en otro - como MVC - no lo he visto claro y lo he dejado atrás.
¿El TDD compensa? Soy todo oidos de lego a las opiniones. :)
Sin tener mucha experiencia, lo hemos utilizado para construir webservices.
Partiendo de la interfaz (wsdl) generamos el esqueleto del webservice y de la implementación (esto es automático) y diseñamos las pruebas (que fallan, ya que el esqueleto no hace nada).
Después se implementa la parte servidora hasta que todas las pruebas pasan.
Esto es muy fácil porque el objetivo es implementar un sistema informático... lo veo mucho más dificil para probar una interfaz web antes de haberla hecho (aunque el patrón PageObjects permite abstraerse del html).
En la práctica, nosotros hacemos poco TDD y más testing "de regresión" (de alguna forma sabemos que algo funciona y añadimos un test que se rompa si eso cambia) o "de confirmación" (cuando algo no está claro -ejemplo real "en este caso ¿el webservice devuelve un array vacío o null?"-, se hace un test y el resultado se pasa a documentación).
No es lo mejor, pero es una solución "pragmática" y fácil de incorporar a nuestro equipo (más que un cambio total en la forma de desarrollar software). Incrementalmente, intentamos añadir algo de TDD (aunque suelen ser pocos tests y casi todos para probar el "exito con datos correctos" y no los caminos laterales).
Un saludo!
--
Abel Muiño - http://ramblingabout.wordpress.com/
Abel Muiño
Sep 18, 2009, 5:30:14 AM9/18/09
to agile...@googlegroups.com
Hola Julio,
Si el desarrollo es puramente técnico, es igual de fácil de probar (implementar ejb o webservice de acceso a funcionalidad existente).
Si tiene interfaz de usuario, antes de hacer ATDD necesitarás definir la interacción del usuario con la página y modelar esa interacción en algo similar a "web objects" (clases de prueba que modelan el contenido de la página sin llegar al html). A medida que implementas la funcionalidad, rellenas los webobjects con el código que interactúa con el HTML (la teoría es que los casos de prueba no verían jamas el html).
El "problema" de esta aproximación es que... ¿no se está volviendo al "big lo-que-sea upfront?"? Planificar la interacción antes de desarrollar, en este caso.
2009/9/18 Julio César Pérez Arques <julio.cesar....@gmail.com>
Luego otra cosa que no tengo muy clara es cómo hacer TDD con pruebas de aceptación (pej pruebas funcionales web), yo tenía entendido que TDD era con pruebas unitarias o de integración.
Si el desarrollo es puramente técnico, es igual de fácil de probar (implementar ejb o webservice de acceso a funcionalidad existente).
Si tiene interfaz de usuario, antes de hacer ATDD necesitarás definir la interacción del usuario con la página y modelar esa interacción en algo similar a "web objects" (clases de prueba que modelan el contenido de la página sin llegar al html). A medida que implementas la funcionalidad, rellenas los webobjects con el código que interactúa con el HTML (la teoría es que los casos de prueba no verían jamas el html).
El "problema" de esta aproximación es que... ¿no se está volviendo al "big lo-que-sea upfront?"? Planificar la interacción antes de desarrollar, en este caso.
Harald
Sep 18, 2009, 5:40:29 AM9/18/09
to agile-spain
Aquí hay otra herramienta para prototipado de aplicaciones web y "made
in spain": http://www.justinmind.com/.
Tiene buena pinta, aunque no lo hemos probado aún, pero me parece
interesante como un ejemplo más de software "made in spain", teniendo
en cuenta que los fabricantes software son los principales usuarios de
"agilidad" y si hay más fabricantes software en España hay más puestos
de trabajo con "agilidad".
Un saludo,
Harald
On 18 sep, 10:57, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> A lo que aporta Harald, puedo añadir que para los prototipos nosotros hemos
> estado usando algunas herramientas muy útiles con las que hemos conseguido
> un prototipo "funcional" sin necesitar de codificar........... Serena
> Prototype Composer es una de esas herramientas, pero hay más ( si necesitais
> os paso nombres ).
>
> Con ello generamos un prototipo que el cliente puede "tocar" y que nos
> aporta un feedback sobre sus requerimientos dinamicos...........ha sido muy
> util.
>
> Saludos.
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> 2009/9/18 Harald <harrin...@gmail.com>
in spain": http://www.justinmind.com/.
Tiene buena pinta, aunque no lo hemos probado aún, pero me parece
interesante como un ejemplo más de software "made in spain", teniendo
en cuenta que los fabricantes software son los principales usuarios de
"agilidad" y si hay más fabricantes software en España hay más puestos
de trabajo con "agilidad".
Un saludo,
Harald
On 18 sep, 10:57, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> A lo que aporta Harald, puedo añadir que para los prototipos nosotros hemos
> estado usando algunas herramientas muy útiles con las que hemos conseguido
> un prototipo "funcional" sin necesitar de codificar........... Serena
> Prototype Composer es una de esas herramientas, pero hay más ( si necesitais
> os paso nombres ).
>
> Con ello generamos un prototipo que el cliente puede "tocar" y que nos
> aporta un feedback sobre sus requerimientos dinamicos...........ha sido muy
> util.
>
> Saludos.
> -----------------------------------------------
> Slitzweitz !!!!!!
>
José Manuel Beas
Sep 18, 2009, 5:41:13 AM9/18/09
to agile...@googlegroups.com
Si tenéis un rato, echad un vistazo a esta presentación (en inglés)
http://tinyurl.com/apnaat
http://tinyurl.com/apnaat
En la diapo #7 hay un diagrama que creo deja bastante clara la
relación entre pruebas de aceptación, pruebas unitarias y TDD.
Simplemente recordar que TDD no hace menos laborioso el desarrollo:
ayuda a hacerlo más fiable. Pero requiere de mucha autodisciplina. Que
nadie piense que ser ágil es hacer las cosas corriendo.
En cuanto a lo del "apfrón" que dice Abel. Hay un libro estupendo (no
es muy largo) titulado "Bridging the Communication Gap" donde habla
bastante sobre el enfoque de "agile acceptance testing". Tengo un
resumen en mi blog [1] por si os apetece leer mis notas.
[1] http://jmbeas.blogspot.com/2009/05/salvando-las-distancias.html
jcesarperez
Sep 18, 2009, 5:45:51 AM9/18/09
to agile-spain
Hola Abel.
> El "problema" de esta aproximación es que... ¿no se está volviendo al "big
> lo-que-sea upfront?"? Planificar la interacción antes de desarrollar, en
> este caso.
Gracias por los comentarios, cuando llegué a casa miraré con detalle
la presentación que comentas (aquí tengo un filtro de contenidos que
me impide ver slideshare).
Me voy a centrar en el tdd web, porque tienes toda la razón cuando los
objetos a probar son ejbs o webservices.
Hacer el test funcional/aceptación web antes de programar no me
preocupa a priori (si es factible). Seguro que me ayuda a definir
mejor el gui y la aplicacion en global. Lo que me preocupa es el
tiempo que me puede llevar implementar ese test que me evade del html
y sobre todo el tiempo que me llevará mantenerlo cuando empiecen a
aparecer los inevitables cambios. Pero es el mismo problema de cuando
haces testing unitario: hay que evaluar el coste/beneficio del caso de
test.
Pero no vas a dejar de ser ágil por análizar y diseñar antes de
desarrollar, dejarás de ser ágil si ese análisis y diseño te lleva 2
semanas en documentación y validaciones antes de que puedas
desarrollar.
Un saludo.
Julio.
> El "problema" de esta aproximación es que... ¿no se está volviendo al "big
> lo-que-sea upfront?"? Planificar la interacción antes de desarrollar, en
> este caso.
la presentación que comentas (aquí tengo un filtro de contenidos que
me impide ver slideshare).
Me voy a centrar en el tdd web, porque tienes toda la razón cuando los
objetos a probar son ejbs o webservices.
Hacer el test funcional/aceptación web antes de programar no me
preocupa a priori (si es factible). Seguro que me ayuda a definir
mejor el gui y la aplicacion en global. Lo que me preocupa es el
tiempo que me puede llevar implementar ese test que me evade del html
y sobre todo el tiempo que me llevará mantenerlo cuando empiecen a
aparecer los inevitables cambios. Pero es el mismo problema de cuando
haces testing unitario: hay que evaluar el coste/beneficio del caso de
test.
Pero no vas a dejar de ser ágil por análizar y diseñar antes de
desarrollar, dejarás de ser ágil si ese análisis y diseño te lleva 2
semanas en documentación y validaciones antes de que puedas
desarrollar.
Un saludo.
Julio.
Jonathan Vila Lopez
Sep 18, 2009, 5:49:05 AM9/18/09
to agile...@googlegroups.com
@Julio Cesar :
Herramientas de prototipado :
+ Serena Prototype Composer [FREE] : http://www.serena.com/Products/prototype-composer/index.html
+ Gui Design Studio : http://www.carettasoftware.com/
+ Axure : http://www.axure.com/
Yo la que más he usado es la de Serena...... permite vincular los prototipos con bases de datos para obtener los datos, genera un fichero que debe abrirse con el software para ejecutar el prototipo.... algun otro genera un html.... Todos tienen una amplia gama de componentes visuales.
Ademas el Serena te permite registrar los comentarios del cliente, y una pequeña gestion del proyecto......
-----------------------------------------------
Slitzweitz !!!!!!
Herramientas de prototipado :
+ Serena Prototype Composer [FREE] : http://www.serena.com/Products/prototype-composer/index.html
+ Gui Design Studio : http://www.carettasoftware.com/
+ Axure : http://www.axure.com/
Yo la que más he usado es la de Serena...... permite vincular los prototipos con bases de datos para obtener los datos, genera un fichero que debe abrirse con el software para ejecutar el prototipo.... algun otro genera un html.... Todos tienen una amplia gama de componentes visuales.
Ademas el Serena te permite registrar los comentarios del cliente, y una pequeña gestion del proyecto......
-----------------------------------------------
Slitzweitz !!!!!!
2009/9/18 Abel Muiño <amu...@gmail.com>
José Manuel Beas
Sep 18, 2009, 5:49:15 AM9/18/09
to agile...@googlegroups.com
2009/9/18 jcesarperez <julio.cesar....@gmail.com>:
>
> Pero no vas a dejar de ser ágil por análizar y diseñar antes de
> desarrollar, dejarás de ser ágil si ese análisis y diseño te lleva 2
> semanas en documentación y validaciones antes de que puedas
> desarrollar.
>
>
> Pero no vas a dejar de ser ágil por análizar y diseñar antes de
> desarrollar, dejarás de ser ágil si ese análisis y diseño te lleva 2
> semanas en documentación y validaciones antes de que puedas
> desarrollar.
>
+1
Harald
Sep 18, 2009, 5:51:54 AM9/18/09
to agile-spain
Sin afán de ser dogmático, pero la potencialidad de TDD la veo en
todos los niveles de pruebas, dado que todos los niveles son otras
perspectivas de la misma solución, simplemente representan otro nivel
de detalle o cubren otros aspectos como p. e. la integración entre
componentes.
Evidentemente utilizar TDD, aunque sea solamente para las pruebas de
aceptación es mejor que no hacerlo, pero la fuerza viene haciendolo en
todos los niveles y automatizando la ejecución en de las pruebas en un
proceso de integración continua. También es evidente que no existen
las herramientas perfectas y que hay algunas lagunas conceptuales para
sacar provecho de toda la potencialidad que tiene TDD, pero si hay una
necesidad alguien las desarrollará.
Un saludo,
Harald
> 2009/9/18 Julio César Pérez Arques <julio.cesar.perez.arq...@gmail.com>
todos los niveles de pruebas, dado que todos los niveles son otras
perspectivas de la misma solución, simplemente representan otro nivel
de detalle o cubren otros aspectos como p. e. la integración entre
componentes.
Evidentemente utilizar TDD, aunque sea solamente para las pruebas de
aceptación es mejor que no hacerlo, pero la fuerza viene haciendolo en
todos los niveles y automatizando la ejecución en de las pruebas en un
proceso de integración continua. También es evidente que no existen
las herramientas perfectas y que hay algunas lagunas conceptuales para
sacar provecho de toda la potencialidad que tiene TDD, pero si hay una
necesidad alguien las desarrollará.
Un saludo,
Harald
> 2009/9/18 Julio César Pérez Arques <julio.cesar.perez.arq...@gmail.com>
Abel Muiño
Sep 18, 2009, 6:10:59 AM9/18/09
to agile...@googlegroups.com
2009/9/18 José Manuel Beas <jose....@gmail.com>
En cuanto a lo del "apfrón" que dice Abel. Hay un libro estupendo (no
es muy largo) titulado "Bridging the Communication Gap" donde habla
bastante sobre el enfoque de "agile acceptance testing". Tengo un
resumen en mi blog [1] por si os apetece leer mis notas.
Justamente estoy "a medio leer" (cuando me queda un rato) ese libro y es uno de los que me ha hecho pensar en ese "apfrón".
Todo por separado no parece dañino, pero cada ingrediente que añado a mi receta ágil me añade un poco más de "apfrón" y causa un cierto escalofrío y sensación de "pero si de ahí es de dónde vengo".
... pero esto es un tema para otra discusión :-)
José Manuel Beas
Sep 18, 2009, 6:13:10 AM9/18/09
to agile...@googlegroups.com
jcesarperez
Sep 18, 2009, 6:28:51 AM9/18/09
to agile-spain
> Evidentemente utilizar TDD, aunque sea solamente para las pruebas de
> aceptación es mejor que no hacerlo, pero la fuerza viene haciendolo en
> todos los niveles y automatizando la ejecución en de las pruebas en un
> proceso de integración continua. También es evidente que no existen
> las herramientas perfectas y que hay algunas lagunas conceptuales para
> sacar provecho de toda la potencialidad que tiene TDD, pero si hay una
> necesidad alguien las desarrollará.
En mi opinión es mucho más fácil hacer TDD en los niveles más bajos de
> aceptación es mejor que no hacerlo, pero la fuerza viene haciendolo en
> todos los niveles y automatizando la ejecución en de las pruebas en un
> proceso de integración continua. También es evidente que no existen
> las herramientas perfectas y que hay algunas lagunas conceptuales para
> sacar provecho de toda la potencialidad que tiene TDD, pero si hay una
> necesidad alguien las desarrollará.
testing (aka unitario).
Como bien ha dicho Abel, aplicarlo a proyectos de EJBs o Webservices
es inmediato porque tienes un interfaz que puedes tocar directamente
sobre código.
Pero aplicarlo al mundo de pruebas de aceptación en aplicaciones web
ricas (ajax), al menos para mi, no es tan inmediato. Al menos en mi
experiencia cuando hemos usado Selenium, tratar con los componentes
ajax no es sencillo. Cada libreria tiene sus hacks y por supuesto las
herramientas visuales (Selenium IDE) no los aplica directamente.
Además hay que sumarle la complejidad/imposibilidad de trabajar sobre
un html que no existe.
No digo que no se pueda hacer, sólo que las cuentas coste/beneficio me
dan para realizar pocos casos de test y bastante básicos o de bugs
detectados a posteriori.
Por favor, si vuestra experiencia es otra a la hora de testear
aplicaciones, iluminarme!
Nota: en mis proyectos todas las pruebas las programa el propio equipo
de desarrollo.
José Manuel Beas
Sep 18, 2009, 6:32:10 AM9/18/09
to agile...@googlegroups.com
Si no automatizas las pruebas de aceptación, ¿cómo estás seguro de que
tu software entregado no estropea funcionalidades anteriores?
¿Haciendo las pruebas de aceptación a mano? Eso quizás funcione en
desarrollos muy pequeños o perfectamente parcelados, pero no es lo
habitual. Así nos va, claro.
2009/9/18 jcesarperez <julio.cesar....@gmail.com>:
tu software entregado no estropea funcionalidades anteriores?
¿Haciendo las pruebas de aceptación a mano? Eso quizás funcione en
desarrollos muy pequeños o perfectamente parcelados, pero no es lo
habitual. Así nos va, claro.
2009/9/18 jcesarperez <julio.cesar....@gmail.com>:
Jonathan Vila Lopez
Sep 18, 2009, 6:36:08 AM9/18/09
to agile...@googlegroups.com
A todo esto, conoceis herramientas que faciliten la creacion/ejecucion de las pruebas de aceptacion ?
-----------------------------------------------
Slitzweitz !!!!!!
-----------------------------------------------
Slitzweitz !!!!!!
2009/9/18 José Manuel Beas <jose....@gmail.com>
Abel Muiño
Sep 18, 2009, 6:46:00 AM9/18/09
to agile...@googlegroups.com
Hola Julio.
En nuestro caso, hemos usado HtmlUnit (todo el código de navegación hecho a mano), en una segunda fase, SeleniumIDE (grabación y pruebas desde el browser) y en la tercera, SeleniumRC (automatización de las pruebas grabadas).
El uso de HtmlUnit ya se ha descartado para el futuro por el coste de aprendizaje y el nivel al que nos movemos (que es más gestión que técnico, así que cuanto menos programar, mejor).
Hemos vivido el problema que comentas (imposibilidad de grabar un test hasta que el desarrollo está complejo, fragilidad de los tests al cambiar el html...) y por eso creo que el concepto de page objects puede ayudar mucho.
Resumiéndolo, en lugar de decir en el test:
- carga el index
- busca la caja de login
- rellena "login"
- busca la caja de password
- rellena "password"
- busca el botón de submit
- haz click en submit
- assert XYZ
(que necesita saber cómo será el html y además es un script y no una especificación -vease Bridging the Communication Gap-).
Debería hacerse este otro:
- Cargar página inicial
- Hacer Login con "login" y "password"
- assert XYZ
(es decir, implementar una interfaz que represente la estructura lógica de la web y las operaciones que se pueden realizar, de forma que esto lo podemos tener antes que el html... aunque al final habrá que rellenar las operaciones con comandos de Selenium o similar, eso detalles no perjudican la estructura de la prueba).
Lamentablemente, no hemos dado ese paso y posiblemente no lo demos (por los perfiles que tenemos en el área), pero si la idea ayuda a alguien, ya me conformo :-)
2009/9/18 jcesarperez <julio.cesar....@gmail.com>
Pero aplicarlo al mundo de pruebas de aceptación en aplicaciones web
ricas (ajax), al menos para mi, no es tan inmediato. Al menos en mi
experiencia cuando hemos usado Selenium, tratar con los componentes
ajax no es sencillo. Cada libreria tiene sus hacks y por supuesto las
herramientas visuales (Selenium IDE) no los aplica directamente.
Además hay que sumarle la complejidad/imposibilidad de trabajar sobre
un html que no existe.
En nuestro caso, hemos usado HtmlUnit (todo el código de navegación hecho a mano), en una segunda fase, SeleniumIDE (grabación y pruebas desde el browser) y en la tercera, SeleniumRC (automatización de las pruebas grabadas).
El uso de HtmlUnit ya se ha descartado para el futuro por el coste de aprendizaje y el nivel al que nos movemos (que es más gestión que técnico, así que cuanto menos programar, mejor).
Hemos vivido el problema que comentas (imposibilidad de grabar un test hasta que el desarrollo está complejo, fragilidad de los tests al cambiar el html...) y por eso creo que el concepto de page objects puede ayudar mucho.
Resumiéndolo, en lugar de decir en el test:
- carga el index
- busca la caja de login
- rellena "login"
- busca la caja de password
- rellena "password"
- busca el botón de submit
- haz click en submit
- assert XYZ
(que necesita saber cómo será el html y además es un script y no una especificación -vease Bridging the Communication Gap-).
Debería hacerse este otro:
- Cargar página inicial
- Hacer Login con "login" y "password"
- assert XYZ
(es decir, implementar una interfaz que represente la estructura lógica de la web y las operaciones que se pueden realizar, de forma que esto lo podemos tener antes que el html... aunque al final habrá que rellenar las operaciones con comandos de Selenium o similar, eso detalles no perjudican la estructura de la prueba).
Lamentablemente, no hemos dado ese paso y posiblemente no lo demos (por los perfiles que tenemos en el área), pero si la idea ayuda a alguien, ya me conformo :-)
José Manuel Beas
Sep 18, 2009, 6:50:44 AM9/18/09
to agile...@googlegroups.com
Abel, ¿qué es eso del "concepto de page object"? ¿Puedes dar alguna referencia?
José Manuel Beas
Sep 18, 2009, 6:54:26 AM9/18/09
to agile...@googlegroups.com
Para usar Concordion sólo necesitas Eclipse (como editor de HTML y
para lanzar el build). Puedes irte también a Fitnesse, que es un wiki
que permite ejecutar pruebas de aceptación usando Fit. Estoy un poco
alejado de Fitnesse, pero creo que UncleBob (el autor de Clean Code)
está mejorándolo, pero no estoy al cabo de los detalles. A mi no me
gusta mucho Fit porque todo tienen que ser tablas y de alguna manera
te empuja a que hagas scripts en vez de especificaciones.
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
para lanzar el build). Puedes irte también a Fitnesse, que es un wiki
que permite ejecutar pruebas de aceptación usando Fit. Estoy un poco
alejado de Fitnesse, pero creo que UncleBob (el autor de Clean Code)
está mejorándolo, pero no estoy al cabo de los detalles. A mi no me
gusta mucho Fit porque todo tienen que ser tablas y de alguna manera
te empuja a que hagas scripts en vez de especificaciones.
2009/9/18 Jonathan Vila Lopez <jonath...@gmail.com>:
jcesarperez
Sep 18, 2009, 6:54:46 AM9/18/09
to agile-spain
@JMB: ¿Me dices a mi? Todas mis pruebas están automatizadas. Me he
tenido que expresar muy mal :-)
Lo que quiero decir es que las pruebas de aceptación web son muy
costosas comparadas con otras pruebas de aceptación (ejbs,
webservices, etc.) y sobre todo con pruebas a otros niveles
(integración, funcional, unitarias). Al menos en mi experiencia. Si
alguno conoce formas de hacerlas de modo ágil, por favor que
comparta...
Pero ya que sacas el tema, en realidad seguro lo que se dice seguro
nunca vas a estar. Al menos el coste de estar 100% seguro es
prohibitivo. Hay que buscar un equilibrio entre la medida de seguro
que quieres obtener y un coste asumible por el equipo tanto en el
desarrollo inicial como en el mantenimiento posterior del codigo de
test. ¿Tema para el Agile-Open? Antes de que me lo encasquetes, tengo
que decirte que no puedo ir (boda, la mia no eh!) :-P
On 18 sep, 12:32, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Si no automatizas las pruebas de aceptación, ¿cómo estás seguro de que
> tu software entregado no estropea funcionalidades anteriores?
> ¿Haciendo las pruebas de aceptación a mano? Eso quizás funcione en
> desarrollos muy pequeños o perfectamente parcelados, pero no es lo
> habitual. Así nos va, claro.
>
> Un saludo,
> Jose Manuel Beas
>
> http://www.agile-spain.comhttp://jmbeas.blogspot.com
>
> 2009/9/18 jcesarperez <julio.cesar.perez.arq...@gmail.com>:
tenido que expresar muy mal :-)
Lo que quiero decir es que las pruebas de aceptación web son muy
costosas comparadas con otras pruebas de aceptación (ejbs,
webservices, etc.) y sobre todo con pruebas a otros niveles
(integración, funcional, unitarias). Al menos en mi experiencia. Si
alguno conoce formas de hacerlas de modo ágil, por favor que
comparta...
Pero ya que sacas el tema, en realidad seguro lo que se dice seguro
nunca vas a estar. Al menos el coste de estar 100% seguro es
prohibitivo. Hay que buscar un equilibrio entre la medida de seguro
que quieres obtener y un coste asumible por el equipo tanto en el
desarrollo inicial como en el mantenimiento posterior del codigo de
test. ¿Tema para el Agile-Open? Antes de que me lo encasquetes, tengo
que decirte que no puedo ir (boda, la mia no eh!) :-P
On 18 sep, 12:32, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> Si no automatizas las pruebas de aceptación, ¿cómo estás seguro de que
> tu software entregado no estropea funcionalidades anteriores?
> ¿Haciendo las pruebas de aceptación a mano? Eso quizás funcione en
> desarrollos muy pequeños o perfectamente parcelados, pero no es lo
> habitual. Así nos va, claro.
>
> Un saludo,
> Jose Manuel Beas
>
> http://www.agile-spain.comhttp://jmbeas.blogspot.com
>
Abel Muiño
Sep 18, 2009, 6:54:59 AM9/18/09
to agile...@googlegroups.com
2009/9/18 José Manuel Beas <jose....@gmail.com>
Abel, ¿qué es eso del "concepto de page object"?
Es un patrón que consiste en modelar la funcionalidad de la web mediante objetos para "aislarse" del HTML.
¿Puedes dar alguna referencia?
Si claro...
Una presentación sobre el concepto de Page Obect: http://www.slideshare.net/dantebriones/using-the-page-object-pattern
Una implementanción (proyecto webdriver): http://code.google.com/p/webdriver/wiki/PageObjects
¡Saludos!
José Manuel Beas
Sep 18, 2009, 6:56:43 AM9/18/09
to agile...@googlegroups.com
2009/9/18 jcesarperez <julio.cesar....@gmail.com>:
>
> ¿Tema para el Agile-Open? Antes de que me lo encasquetes, tengo
> que decirte que no puedo ir (boda, la mia no eh!) :-P
>
> ¿Tema para el Agile-Open? Antes de que me lo encasquetes, tengo
> que decirte que no puedo ir (boda, la mia no eh!) :-P
Suena a excusa barata. :-D
jcesarperez
Sep 18, 2009, 7:00:37 AM9/18/09
to agile-spain
Nosotros también usamos Selenium RC e intentamos hacer un html
"amigable" que facilite la creación de los tests.
El otro día vi SeleniumInspector [1], un "plugin" de Selenium RC, aún
no lo he probado, pero me parece que se parece bastante al concepto
que comentas y desde luego tengo que probarlo! Aunque no sé si sabes
que el proyecto Selenium va a sufrir un importante cambio al
fusionarse con Webdriver[2] en la siguiente versión.
[1]: http://seleniuminspector.org/
[2]: http://code.google.com/p/webdriver/
On 18 sep, 12:46, Abel Muiño <amu...@gmail.com> wrote:
> Hola Julio.
>
> 2009/9/18 jcesarperez <julio.cesar.perez.arq...@gmail.com>
"amigable" que facilite la creación de los tests.
El otro día vi SeleniumInspector [1], un "plugin" de Selenium RC, aún
no lo he probado, pero me parece que se parece bastante al concepto
que comentas y desde luego tengo que probarlo! Aunque no sé si sabes
que el proyecto Selenium va a sufrir un importante cambio al
fusionarse con Webdriver[2] en la siguiente versión.
[1]: http://seleniuminspector.org/
[2]: http://code.google.com/p/webdriver/
On 18 sep, 12:46, Abel Muiño <amu...@gmail.com> wrote:
> Hola Julio.
>
> 2009/9/18 jcesarperez <julio.cesar.perez.arq...@gmail.com>
Abel Muiño
Sep 18, 2009, 7:02:07 AM9/18/09
to agile...@googlegroups.com
2009/9/18 José Manuel Beas <jose....@gmail.com>
Proponla para el Agile Open. :-)
De momento, me he apuntado a la lista de espera, aunque mi impulso inicial era meditar un poco más y llevar la discusión a foro-agiles (que también lo haré si tengo un hueco antes de mis vacaciones).
José Manuel Beas
Sep 18, 2009, 7:06:11 AM9/18/09
to agile...@googlegroups.com
Vale, ¡Webdriver! Sí claro, he probado Selenium Webdriver [1] y es
estupendo, pero no muy diferente de HttpUnit. Quizás no he visto la
ventaja porque mi prueba ha sido con Wicket y además muy pequeña la
prueba. Probablemente, cuando pueda continuar con el ejercicio veré
más sobre las ventajas / desventajas. Miraré la teoría porque creo que
me estoy perdiendo algo.
[1] http://jmbeas.blogspot.com/2009/01/pruebas-funcionales-automatizadas-de.html
2009/9/18 Abel Muiño <amu...@gmail.com>:
estupendo, pero no muy diferente de HttpUnit. Quizás no he visto la
ventaja porque mi prueba ha sido con Wicket y además muy pequeña la
prueba. Probablemente, cuando pueda continuar con el ejercicio veré
más sobre las ventajas / desventajas. Miraré la teoría porque creo que
me estoy perdiendo algo.
[1] http://jmbeas.blogspot.com/2009/01/pruebas-funcionales-automatizadas-de.html
2009/9/18 Abel Muiño <amu...@gmail.com>:
José Manuel Beas
Sep 18, 2009, 7:07:39 AM9/18/09
to agile...@googlegroups.com
2009/9/18 Abel Muiño <amu...@gmail.com>:
>
>
> 2009/9/18 José Manuel Beas <jose....@gmail.com>
>>
>> Proponla para el Agile Open. :-)
>
> De momento, me he apuntado a la lista de espera, aunque mi impulso inicial
> era meditar un poco más y llevar la discusión a foro-agiles (que también lo
> haré si tengo un hueco antes de mis vacaciones).
>
>
>
> 2009/9/18 José Manuel Beas <jose....@gmail.com>
>>
>> Proponla para el Agile Open. :-)
>
> De momento, me he apuntado a la lista de espera, aunque mi impulso inicial
> era meditar un poco más y llevar la discusión a foro-agiles (que también lo
> haré si tengo un hueco antes de mis vacaciones).
>
Otro con excusa. ¡Y además muy barata! ¿Pero qué es lo que tienes que
meditar para proponer algo en el Open? :-D
Un saludo,
JMB
Abel Muiño
Sep 18, 2009, 7:11:29 AM9/18/09
to agile...@googlegroups.com
2009/9/18 jcesarperez <julio.cesar....@gmail.com>
Nosotros también usamos Selenium RC e intentamos hacer un html
"amigable" que facilite la creación de los tests.
El otro día vi SeleniumInspector [1], un "plugin" de Selenium RC, aún
no lo he probado, pero me parece que se parece bastante al concepto
que comentas y desde luego tengo que probarlo!
Le acabo de dar un vistazo y sigue "pegado" a la estructura del HTML, aunque menos que Selenium, y creo que vale la pena usarlo.
La idea que yo veo detrás de page objects es abstraers de la estructura y probar la interacción.
Por ejemplo, una web de juguete en la que la que el usuario tiene 3 posibilidades: (login, registro y búsqueda) se modelaría como un objeto con tres métodos (login, registro y busqueda) y podrías hacer pruebas como que el resultado de hacer login con un usuario que no existe es un mensaje de error sin tener una línea de html.
Aunque no sé si sabes
que el proyecto Selenium va a sufrir un importante cambio al
fusionarse con Webdriver[2] en la siguiente versión.
Había visto que los proyectos estaban muy relacionados, pero no sabía que el plan era fusionarse. Me parece buena idea y tiene muchas posibilidades (Selenium es de Thoughtworks, Webdriver de Google... si entre los dos no hacen "la solución definitiva", mal vamos los simples mortales :-) ).
Xavi Gost
Sep 18, 2009, 7:44:06 AM9/18/09
to agile...@googlegroups.com
Mi pequeña aportacion al tema TDD.
Personalmente yo desvinculo la practica del TDD de la de tener test
unitarios, test funcionales y todo eso...
Me explico un poco, yo uso TDD como una manera de programar, me obliga
a realizar test que son absurdos, muchos de ellos son absolutamente
utilitarios para llevar el codigo al sitio que me interesa, gran parte
de ellos son borrados /refactorizados antes del commit.
TDD lo que me permite es :
-Romper el miedo a la pagina en blanco.. empiezo por un sencillo
problema (la mayoria de las veces testeando que tras la instancia
dispongo de una constante, o que la instancia es un singleton , o que
la factoria me devuelve una instancia..)
-Obtener "flow" cuando estoy programando y recuperar facilmente el
"flow" cuando empiezo una sesion (dejate siempre un test hecho que da
rojo antes de cerrar una sesion, pero despues del commit ehh!!)
-Hacer visible la estructura/diseño/arquitectura del artefacto
software que estoy construyendo
-Si me apuras hasta me sirve en muchos casos de documentacion para
transmitir mis intenciones..
En otro orden de cosas como herramienta para hacer formacion, no tiene precio..
Lectura al respecto el libro de Beck es un paso a paso imposible de no entender.
Atendiendo a otros (muchos) topics en este post:
Selenium solo para testear estructura de la pagina (cuidado que si no
usas un XHTML bueno te acoplas del carajo) y funcionamiento de los
javascripts (si fuese necesario, creo que hay librerias/entornos que
permiten mejor el testeo de funciones javascript).
En una estructura MVC pues tiendo a testar(poco) los controladores,
basicamente validaciones
La vista bueno.. ya he dicho lo de Selenium
y el Modelo... bueno tiendo a que las estructuras que son el modelo en
el framework sean solo fachadas a mi Dominio (como es mi Dominio ahi
soy el rey y testear no es un problema)
En aplicaciones sobre J2E o spring o XXXFramework tengo especial
cuidado en no andar probando el framework mismo (me parece una
tonteria pero es facil caer ahi)
Vale decir que soy absolutamente incapaz de programar un helloworld
sin usar TDD, para mi es una de las disciplinas fundamentales para un
programador que se encuentre en el lado luminoso de la fuerza.
Ahh y como "disclaimer" soy de los que piensan en esta profesion como
una artesania no como una ingenieria
Xavier Gost
José Manuel Beas
Sep 18, 2009, 7:53:36 AM9/18/09
to agile...@googlegroups.com
No sé si animarte a una sesión práctica de TDD en el Open porque he
programado contigo y eres lento de c.......nes pero no estaría nada
mal que te atrevieras a liderar una sesión de ping pong programming
(P3) :-D
[P3] http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
2009/9/18 Xavi Gost <xav...@gmail.com>:
programado contigo y eres lento de c.......nes pero no estaría nada
mal que te atrevieras a liderar una sesión de ping pong programming
(P3) :-D
[P3] http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
2009/9/18 Xavi Gost <xav...@gmail.com>:
Xavi Gost
Sep 18, 2009, 8:03:04 AM9/18/09
to agile...@googlegroups.com
José Manuel Beas
Sep 18, 2009, 8:13:45 AM9/18/09
to agile...@googlegroups.com
Bueno, tú preparas el ejercicio y lo facilitas y el resto de los que
vayamos nos vamos turnando. Tampoco es tan difícil. :-p
vayamos nos vamos turnando. Tampoco es tan difícil. :-p
Carlos Ble
Sep 18, 2009, 8:19:17 AM9/18/09
to agile-spain
Vaya!
Que hilo tan largo en un momento. Que rapidez :-)
En verdad hay mucho que escribir y mucho que leer al respecto pero
la verdadera comprension llega cuando se practica.
Si todo sigue como va, para diciembre publico un libro sobre TDD
en castellano donde hablo de todos estos temas y se dan
ejemplos practicos. Cuando salga lo comunico en esta lista.
Pienso que hace falta mucha documentacion en castellano al respecto.
Opino que seria conveniente trasladar la discusion sobre tdd a la
lista
que se creo para ello, como apunto JM Beas.
Saludos cordiales
On 18 sep, 09:01, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Hola a todos.
>
> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> interesante ......... pero no veo la forma práctica de abordarlo.
>
> El principio básico, sin no he entendido mal, reside en desarrollar los
> casos de test antes de desarrollar el software...... pero, como puedo probar
> algo que no está desarrollado ? creo el método del test pero luego que hago
> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> como puedo controlar si tal operación da el resultado esperado o no ?
>
> Seguramente algo he entendido mal........
>
> Saludos.
> Jonathan V.
>
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> On Fri, Sep 18, 2009 at 9:54 AM, José Manuel Beas <jose.m.b...@gmail.com>wrote:
>
>
>
> > ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> > a incorporarse a la comunidad?
>
> > > Me parece interesante y .. como van unos años por delante pues....
>
> > > I feel majority of the Agile community has got into a “preaching mode”
> > > and very few people are actually building their own products (eating
> > > their own dog food.) This attitude attracts a certain kind of people
> > > to the conference and I’m quite skeptical to find innovative new ideas
> > > in this crowd. With so much noise its also very easy to miss some weak
> > > signals which have potential.
>
> > > I do know a few people who are doing some really interesting stuff
> > > (they are turned off by the Agile brand and generally don’t hang
> > > around in these circles). Personally I want us, as a community, to be
> > > more inclusive of these people.
>
> > > Xavier Gost
Que hilo tan largo en un momento. Que rapidez :-)
En verdad hay mucho que escribir y mucho que leer al respecto pero
la verdadera comprension llega cuando se practica.
Si todo sigue como va, para diciembre publico un libro sobre TDD
en castellano donde hablo de todos estos temas y se dan
ejemplos practicos. Cuando salga lo comunico en esta lista.
Pienso que hace falta mucha documentacion en castellano al respecto.
Opino que seria conveniente trasladar la discusion sobre tdd a la
lista
que se creo para ello, como apunto JM Beas.
Saludos cordiales
On 18 sep, 09:01, Jonathan Vila Lopez <jonathan.v...@gmail.com> wrote:
> Hola a todos.
>
> Estos días he estado leyendo un poquito sobre TDD y lo he visto muy
> interesante ......... pero no veo la forma práctica de abordarlo.
>
> El principio básico, sin no he entendido mal, reside en desarrollar los
> casos de test antes de desarrollar el software...... pero, como puedo probar
> algo que no está desarrollado ? creo el método del test pero luego que hago
> dentro ? si aún no tengo las clases creadas y con los métodos implementados
> como puedo controlar si tal operación da el resultado esperado o no ?
>
> Seguramente algo he entendido mal........
>
> Saludos.
> Jonathan V.
>
> -----------------------------------------------
> Slitzweitz !!!!!!
>
> On Fri, Sep 18, 2009 at 9:54 AM, José Manuel Beas <jose.m.b...@gmail.com>wrote:
>
>
>
> > ¿Cómo propones incluir a esos buenos practicantes pero que son reacios
> > a incorporarse a la comunidad?
>
> > Un saludo,
> > Jose Manuel Beas
>
> >http://www.agile-spain.com
> >http://jmbeas.blogspot.com
>
> > 2009/9/18 Xavi Gost <xavi...@gmail.com>:
> > Un saludo,
> > Jose Manuel Beas
>
> >http://www.agile-spain.com
> >http://jmbeas.blogspot.com
>
>
> > > Me parece interesante y .. como van unos años por delante pues....
>
> > > I feel majority of the Agile community has got into a “preaching mode”
> > > and very few people are actually building their own products (eating
> > > their own dog food.) This attitude attracts a certain kind of people
> > > to the conference and I’m quite skeptical to find innovative new ideas
> > > in this crowd. With so much noise its also very easy to miss some weak
> > > signals which have potential.
>
> > > I do know a few people who are doing some really interesting stuff
> > > (they are turned off by the Agile brand and generally don’t hang
> > > around in these circles). Personally I want us, as a community, to be
> > > more inclusive of these people.
>
> > > Xavier Gost
Xavi Gost
Sep 18, 2009, 8:24:40 AM9/18/09
to agile...@googlegroups.com
Eres un "Chicken", no hay nada que preparar solo dos personas
dispuestas a divertirse haciendo codigo....
dispuestas a divertirse haciendo codigo....
Ademas ya es tarde, mira la pagina de sesiones del Agile open Spain
JE je je ....
Xavier Gost
José Manuel Beas
Sep 18, 2009, 8:35:59 AM9/18/09
to agile...@googlegroups.com
¡Qué c....ón que eres! ¿Me tengo que llevar el kimono? :-D
A ver si podemos grabarlo, puede ser chulo, por lo menos divertido. :-D
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.blogspot.com
2009/9/18 Xavi Gost <xav...@gmail.com>:
>
A ver si podemos grabarlo, puede ser chulo, por lo menos divertido. :-D
Un saludo,
Jose Manuel Beas
http://www.agile-spain.com
http://jmbeas.blogspot.com
2009/9/18 Xavi Gost <xav...@gmail.com>:
>
Jose R.
Sep 18, 2009, 12:39:39 PM9/18/09
to agile...@googlegroups.com
Hola!
Interesante charla!
Os cuento nos nuestra experiencia en TDD, y por la que decidimos abrir la lista de TDD en castellano desde Biko.
A finales del año pasado, en una retrospectiva anual del equipo JAVA de Biko, salieron como objetivos el tener pruebas unitarias con una cobertura decente, y finalizar haciendo TDD, entre otras cosas :)
La implantación en equipos de estas técnicas es costosa, ocho personas que no habíamos hecho TDD anteriormente nunca más las típicas prisas en una empresa de servicios de vez en cuando. No hemos llegado a realizar TDD de manera continua, y ahora empezamos con temas de Selenium, pero ciertamente hemos empezado a ver los beneficios en proyectos que han disminuido su número de incidencias de manera considerable.
Yo no tengo duda que es una técnica que se impondrá como natural en un tiempo, que aporta beneficios claros, pero que no es sencilla de implantar en medio de un proyecto en marcha, o asimilar por los equipos. La falta de información en castellano tambien es un handicap a veces, no tanto la información "estática", si no la agilidad de las preguntas y respuestas en un foro. Esperamos ansiosos el libro, Carlos ;)
Salu2
Joserra
Interesante charla!
Os cuento nos nuestra experiencia en TDD, y por la que decidimos abrir la lista de TDD en castellano desde Biko.
A finales del año pasado, en una retrospectiva anual del equipo JAVA de Biko, salieron como objetivos el tener pruebas unitarias con una cobertura decente, y finalizar haciendo TDD, entre otras cosas :)
La implantación en equipos de estas técnicas es costosa, ocho personas que no habíamos hecho TDD anteriormente nunca más las típicas prisas en una empresa de servicios de vez en cuando. No hemos llegado a realizar TDD de manera continua, y ahora empezamos con temas de Selenium, pero ciertamente hemos empezado a ver los beneficios en proyectos que han disminuido su número de incidencias de manera considerable.
Yo no tengo duda que es una técnica que se impondrá como natural en un tiempo, que aporta beneficios claros, pero que no es sencilla de implantar en medio de un proyecto en marcha, o asimilar por los equipos. La falta de información en castellano tambien es un handicap a veces, no tanto la información "estática", si no la agilidad de las preguntas y respuestas en un foro. Esperamos ansiosos el libro, Carlos ;)
Salu2
Joserra
2009/9/18 José Manuel Beas <jose....@gmail.com>
Alfredo Casado
Sep 18, 2009, 1:22:45 PM9/18/09
to agile...@googlegroups.com
Nosotros hace un año y pico empezamos a tomarnos muy serio el tema de unit testing, sin llegar a hacer TDD al principio sino simplemente ir escribiendo las pruebas despues o durante. Es MUY dificil cambiar la forma de trabajo y acostumbrarse a que no se puede escribir código de producción si no es para hacer pasar un test que falla, a mi me gustán las 3 reglas de robert martin sobre TDD:
1 - obviamente probar que el código hace lo que yo quiero que haga.
2 - es una tecnica de DISEÑO.
Y este segundo punto es importantisimo, lo dificil no es escribir pruebas, lo dificil es escribir código testable!, tu codigo debe seguir algunos principios que no de seguirlos haran casi imposible el uso de TDD:
- Que este poco acoplada (cuidado con new y con los estaticos).
- Que tenga una responsabilidad bien definida y hago poco y bien sino los test se vuelven inmanejables.
- No usar estado global, sino los test serán dependientes unos de otros.
- Usar inyección de dependencias es casi imprescindible para hacer TDD.
- No hacer trabajo en los constructores.
- Preferir composición sobre herencia. La herencia dificulta mucho los test unitarios.
Todas estas normas, son buenas practicas que se puede aplicar generalmente, y hacer TDD te obliga a cumplirlas, o eso o dejas de hacer TDD porque se vuelve imposible. Misko Hevery tiene un blog muy bueno sobre esto, y un pdf con buenas normas para hacer código testable.
Otra buena practica con la que cometimos muchos errores al principio fue no tratar al código de los test con el mismo respeto que al resto, es decir, haz código de test limpio, legible, bien estructurado... si no al final terminas con una bateria de test que no hay quien mantenga y que tienes que tirar a la basura.
Por otro lado también hacemos ATDD, el flujo de trabajo suele ser primero una prueba funcional de aceptación y luego nos ponemos a implementar las clases necesarias para cumplir ese test usando TDD.
Decir que nuestro producto final es fundamentalmente un API, un framework para desarrollar sobre el otras aplicaciones, con lo que es más facil hacer test de aceptación, también tenemos alguna UI web con GWT/SmartGWT y para estas de momento no tenemos pruebas automaticas, en realidad no hacen gran cosa porque casi todo consiste en capturar el evento del usuario invocar al API y mostrar al resultado, son bastante "tontas", pero sin duda es el punto debil más gordo de nuestro desarrollo actual, tendremos que mejorar en esto.
Sobre si esta practica compensa, yo diria que es la practica que como programador más me ha compesado con diferencia, a día de hoy no me puedo imaginar hacer un desarrollo sin usar TDD, es como salir desnudo a la calle xd. Hacer un cambio y romper siete cosas relacionadas, sesiones de debug interminables para detectar un bug, código que nadie se atreve a refactorizar casi ni a mirarlo por si se rompe... no, definitivamente no quiero volver a eso.
- No esta permitido escribir código de producción si no es para hacer pasar un test que falla.
- No esta permitido seguir escribiendo un test si ya tiene suficiente código para fallar; y los errores de compilación son fallos.
- No esta permitido escribir más código de producción del estrictamente necesario para que pase el test.
1 - obviamente probar que el código hace lo que yo quiero que haga.
2 - es una tecnica de DISEÑO.
Y este segundo punto es importantisimo, lo dificil no es escribir pruebas, lo dificil es escribir código testable!, tu codigo debe seguir algunos principios que no de seguirlos haran casi imposible el uso de TDD:
- Que este poco acoplada (cuidado con new y con los estaticos).
- Que tenga una responsabilidad bien definida y hago poco y bien sino los test se vuelven inmanejables.
- No usar estado global, sino los test serán dependientes unos de otros.
- Usar inyección de dependencias es casi imprescindible para hacer TDD.
- No hacer trabajo en los constructores.
- Preferir composición sobre herencia. La herencia dificulta mucho los test unitarios.
Todas estas normas, son buenas practicas que se puede aplicar generalmente, y hacer TDD te obliga a cumplirlas, o eso o dejas de hacer TDD porque se vuelve imposible. Misko Hevery tiene un blog muy bueno sobre esto, y un pdf con buenas normas para hacer código testable.
Otra buena practica con la que cometimos muchos errores al principio fue no tratar al código de los test con el mismo respeto que al resto, es decir, haz código de test limpio, legible, bien estructurado... si no al final terminas con una bateria de test que no hay quien mantenga y que tienes que tirar a la basura.
Por otro lado también hacemos ATDD, el flujo de trabajo suele ser primero una prueba funcional de aceptación y luego nos ponemos a implementar las clases necesarias para cumplir ese test usando TDD.
Decir que nuestro producto final es fundamentalmente un API, un framework para desarrollar sobre el otras aplicaciones, con lo que es más facil hacer test de aceptación, también tenemos alguna UI web con GWT/SmartGWT y para estas de momento no tenemos pruebas automaticas, en realidad no hacen gran cosa porque casi todo consiste en capturar el evento del usuario invocar al API y mostrar al resultado, son bastante "tontas", pero sin duda es el punto debil más gordo de nuestro desarrollo actual, tendremos que mejorar en esto.
Sobre si esta practica compensa, yo diria que es la practica que como programador más me ha compesado con diferencia, a día de hoy no me puedo imaginar hacer un desarrollo sin usar TDD, es como salir desnudo a la calle xd. Hacer un cambio y romper siete cosas relacionadas, sesiones de debug interminables para detectar un bug, código que nadie se atreve a refactorizar casi ni a mirarlo por si se rompe... no, definitivamente no quiero volver a eso.
José Manuel Beas
Sep 18, 2009, 5:28:17 PM9/18/09
to agile...@googlegroups.com
El blog de Misko Hevery es estupendo y además tiene una herramienta
llamada testability explorer que tiene muy buena pinta. Si alguien lo
ha probado, sería genial que lo compartiera.
2009/9/18 Alfredo Casado <casado....@gmail.com>:
llamada testability explorer que tiene muy buena pinta. Si alguien lo
ha probado, sería genial que lo compartiera.
2009/9/18 Alfredo Casado <casado....@gmail.com>:
Reply all
Reply to author
Forward
0 new messages