[agile-spain] [TDD] Primeros pasos

[Jorge Jimenez]

Abro este hilo ya que la conversación del otro hilo derivaba por otras hsitorias...

Hola a todos!!

Yo soy un auténtico profano en esto de TDD, ATDD y demás xxDD's que existan, salvo mis pobrecitos test unitarios, y los de integración de toda la vida ;-)

Asistí a  la charla de Carlos Ble y Agustín Yagüe en el Agile Open Spain poque me parecía interesante lo poco que había leido de ello y porque me interesa ese enfoque de la forma de desarrollar, pero debo reconocer que estoy bastante cercano a la opinión de Juan Carlos (aunque sea de .NET ). Me resulta bastante complejo cambiar la forma de afrontar el desarrollo utilizando TDD. Es la primera vez que ante algo nuevo en esto de la informática siento que no soy capaz de abordarlo.

Decir que la sesión de Carlos consiguió captar mi atención y las ganas de entender más TDD (con lo cual para mi fue un éxito de sesión) y estoy esperando con ganas ese libro que está trabajando...pero ahora empieza lo duro.

La verdad es que la filosofía que hay detrás de su mecánica es muy bonita, o por decirlo mejor, demasiado ideal. también es verdad que a lo mejor hya entornos en que no se puede aplicar (no todo va a ser blanco o negro), pero llevarlo a la práctica me resulta difícil. Seguramente porqué no sé por donde empezar.

Los primeros pasos que estoy dando es enterarme más de asunto (mediante este hilo, algunas páginas y el libro de Koskela que lo tengo de cabecera de cama).

Me gustaría saber, por los que ya lo estáis trabajando si recomendais empezar por algo más o no para ver si me actualizo yo y el equipo en el que trabajo.


Un saludo

Jorge Jiménez

http://azucarenlasvenas.blogspot.com

[Jose R.]

Hola!

 Os recuerdo la existencia de un grupo de correo de TDD: http://groups.google.com/group/tddev-sp , está un poco en stand-by ultimamente, pero ahí estamos ;)
 Por lo que he visto yo en la gente más experimentada llegar a TDD es un proceso complejo, así que no te asustes :D
  Cuando la gente controla de testeo unitario, empieza a experimentar haciendo los test antes (eso sí, si lo leemos o nos lo dicen, creo que a casi nadie se le ocurre espontaneamente). Luego se le coge el gusto. Pero haces TDD cuando ya has decidido practicamente la interfaz y el diseño de tus clases... y vas haciendo TDD de cada método o clase. Un verdadero diseño emergente no lo he visto en acción :\
  Pero claro, hasta que llegas al desarrollo de la interfaz, entonces te metes en otro mundo... que es muy dificil hacer TDD.

 Salu2!

   joserra

2009/11/5 Jorge Jimenez <sem...@gmail.com>

[Juan Carlos Quijano Abad]

Holassss

Gracias, por la url a tí y a JMB. Ya he solicitado el ingreso en el foro.

--
Un saludo
Juan Quijano

[José Manuel Prieto]

yo tambien

Jose Manuel Prieto

--
Jose Manuel Prieto
http://josemanuel.prietopalacios.net

[Nacho Rodriguez]

Yo tambien.
He leido los ultimos mensajes y hablan de conseguir mulatitas wenas y ganar 500$ al dia.
¡Tiene buena pinta!

:D

2009/11/5 José Manuel Prieto <priet...@gmail.com>

[Carlos Ble]

Gracias Jorge por el feedback :-)

Como dice Peter Provost en un video que tengo enlazado en el ultimo
post que escribi en ingles en mi blog (carlosble.com): just do it,
just start.

No esperes a que termine el libro. Mandame un email privado y te mando
el .pdf para que tengas más ayuda ya.
Cree en ti mismo y ponte a practicar. Será la unica forma de aprender.

<publicidad type="descarada">
Por otra parte, si tu empresa puede contratar un curso sobre TDD yo
estaré encantado de desplazarme hasta alli y darlo. O si consigues
reunir a un grupo de personas en tu zona tambien podemos organizarlo.
</publicidad>

Para preguntas concretas está la lista que comenta Joserra, aunque
como dice Nacho, tendriamos que quitarle
el spam.
Apuntate a la lista de TDD de yahoo si no te da miedo el ingles, es
una lista donde he aprendido muchisimo.

Saludos cordiales :-)

[José Manuel Beas]

Sé que los puristas os tiraréis encima mío enseguida, pero a mi me gusta el TestFirstChallenge [1] como ejercicio para enfrentarse a TDD (sin todas las dificultades de TDD, como tener que concebir los tests). La ventaja de tener los tests escritos es también la desventaja, pero al menos ayuda rebajando la pendiente de aprendizaje.

[1] http://xp123.com/xplor/xp0201/

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com

[Juan]

Creo que tener las pruebas escritas desde el principio le quita mucha
"chicha" al asunto y una de las cosas principales del tema: pensar
primero en cómo vas a probar lo que quieres codificar (y no, no me
considero un purista, JMB :-) )

Estoy con Carlos al 100% en que el único camino es ponerse a prácticar
y darle caña al asunto. Por supuesto hay maneras y maneras de empezar.
Yo recomendaría ponerse con algún ejercicio más o menos sencillo (por
ejemplo, yo suelo usar para los cursos de introducción ejercicios del
"ACM programming contest" que se pueden encontrar aquí http://uva.onlinejudge.org/)
que te vayan metiendo en el ritmo de TDD poco a poco. Por ejemplo,
primero unos cuantos ejercicios que no requieran mocking, luego
pasarse a otros donde pueda usarse mocking sencillo, etc. Cuando te
empieces a sentir cómodo, pasa a un problema real, etc, etc.

Más tarde o más temprano verás que instintivamente empezaras a
programar de esta manera cualquier problema... ;-)

Por supuesto, el cambio en la manera de trabajar no garantiza que las
pruebas y el código sean excelente pero ya tienes mucho hecho. Libros
en el tema, cursos (como los de Carlos -10% por el marketing :-D-) o
"hands-on coaching" pueden ayudarte a mejorar la calidad de las
pruebas y del código.

Saludos,

Juan

[Mari Carmen Gutierrez De La Ossa]

Buenas noches,

irrumpo estruendosamente y por primera vez en la lista para daros las
gracias por las estupendas aportaciones que hacéis todos y que hacen
que los que sabemos poco, vayamos cogiendo el hilo del asunto del
desarrollo ágil.

Yo personalmente estoy empezando en este mundo (en concreto en el
ámbito web) empleando RoR. Desde la comunidad que hay detrás se
promueve exhaustivamente el TDD y yo, como curiosa y hambrienta de
aprender que soy, me he lanzado (algunas directrices recibidas
mediante) a practicarlo en el desarrollo de mi propio proyecto de fin
de carrera. Me encuentro con dificultades, por supuesto, pero la
satisfacción de *creer* que hago las cosas mejor, la sensación de
avance que te produce y lo claramente que te obliga a pensar en la
funcionalidad de tu aplicación, hacen que le esté cogiendo el gusto a
ritmo de vértigo. ¡Y no hago más que testear modelos por el momento!

Ahora que estoy empezando, empiezo a creer firmemente que el TDD es el
camino. Sin embargo me gustaría compartir con vosotros las reflexiones
[1] al respecto de un amigo que sabe bastante del asunto, en concreto
trabajando con RoR. Esto a su vez me da qué pensar: ¿cómo distinguir
cuándo realmente la balanza se inclina a favor del TDD? Me gustaría
leer vuestras experiencias personales al respecto, si es que en algún
momento os habéis visto en semejante brete.

Gracias de antemano por toda vuestra sabiduría depositada aquí para el
disfrute del personal :D

Mari.

[1] http://porras.lacoctelera.net/post/2009/04/30/el-emperador-esta-pelotas

--
http://www.valakirkasasylum.blogspot.com
http://valakirka.lacoctelera.net
http://twitter.com/valakirka

"To err is human. To really screw up requires root password."

[agusti...@gmail.com]

Como ya te han comentado en otros mensajes la cuestión es que empieces
ya a aplicarlo.
Además creo que el complemento perfecto para que veas tu progreso es
un servidor
de integración contínua y que puedas ver gráficamente tus progresos.

Yo he empezado a evangelizar (me gusta el término) en TDD y te puedo
asegurar que esto es como un veneno, si consigues captar su atención
desde
el principio, se pican y el progreso es significativo.

Por supuesto, requiere un esfuerzo y una disciplina importante.
Yo te recomiendo que empieces, si tu tiempo te lo permite, por
aplicarlo todos los
días durante un tiempo breve (1 hora) y verás como en poco tiempo has
cogido
soltura y empiezas a cambiar tu forma de resolver problemas.

[Jose R.]

Yo suelo decir que el programador que no sepa utilizar TDD estará fuera de mercado en 3 años. Eso siendo optimistas ;)

2009/11/7 agusti...@upm.es <agusti...@gmail.com>

[Éric Mignot]

Hola!

Como dicho en el post mencionado, analizar la productividad del TDD nos lleva a discusiones sin salida clara. Yo comparto esa opinion. Sobre todo porque siempre tendra uno en la sala con un ejemplo de fracaso que atribuye al tdd mismo.

Para mi una de la ventajas mas apreciable del tdd es que aumenta mi placer al trabajo. Mas serenidad, mas colaboracion. Dificil de poner esto en una hoja de Excel.

Eric

[Mari Carmen Gutierrez De La Ossa]

Para mi una de la ventajas mas apreciable del tdd es que aumenta mi
placer al trabajo. Mas serenidad, mas colaboracion. Dificil de poner
esto en una hoja de Excel.

Eso es lo único que yo quería conocer, vuestras impresiones al
respecto :). Nada de hojas de excel, no se trata de establecer un
umbral exacto, sino de sondear un poco las experiencias en caso de que
en algún momento os hubiérais encontrado con que quizá era pertinente
relajar la exhaustividad del TDD (nunca suprimirlo completamente,
claro) en pro de sacar algo adelante. Obviamente la situación que
expone el post es extrema e irreal. ¿O existen situaciones parecidas
en vuestros entornos?

En definitiva, gracias por haber compartido vuestra valiosa opinión!

2009/11/9 Éric Mignot <emi...@pyxis-tech.com>:

[Alfredo Casado]

Hombre es que para un spike, una prueba de concepto. un código que escribes y sabes que va a ir directamente a la basura o en caso de seguir lo vas a reescribir hacer pruebas automaticas puede que no tenga mucho sentido. Para cualquier otro caso que no sea este extremo hacer TDD aporta un gran valor.

Decia alguien que el factor más importante para la productividad de mañana es la calidad del código que escribes hoy, estoy totalmente de acuerdo con esta afirmación, ni siquiera hay que esperar a la fase de mantenimiento de un proyecto para ver la rentabilidad de hacer pruebas, sin pruebas automaticas en menos tiempo de lo que piensas habras perdido el control de tu proyecto y luego cuesta mucho reconducir las cosas.

[jorge]

Perdona Alfredo pero ¿podrías desarrollar un poco más lo de las pruebas automáticas y el TDD? No entiendo lo de escribir código que luego vas a tirar a la basura o reescribirlo...

gracias

2009/11/9 Alfredo Casado <casado....@gmail.com>

[Alfredo Casado]

Hola jorge,

Me referia a casos como el de la entrada del blog que ha puesto mari carmen, un código que haces para un hack-day en una tarde simplemente por practicar con tal o cual tecnología, este código lo más probable es que acabe en la basura, en estos casos quizas no te merezca la pena montarle toda una bateria de pruebas automaticas.

Lo de reescribirlo es porque si luego el resultado de la prueba te gusta y lo vas a incluir en un proyecto real o va a servir como comienzo de un proyecto más largo, pues lo más probable es que lo termines reescribiendo con un poco más de cuidado en el diseño e incluyendo pruebas.

[jorge]

crystal clear.

no seguí el hilo del hack-day realmente ;)

2009/11/9 Alfredo Casado <casado....@gmail.com>

[José Manuel Beas]

Sólo una confidencia... aquí, entre nosotros... un día le pregunté a Kent Beck sobre cómo planteaba él las pruebas del plugin eclipse para JUnit y me dijo:

Thank you for the message. My earlier book with Erich Gamma, Contributing to Eclipse, talks about how to develop plug-ins test-first. Unfortunately it uses an old version of Eclipse, so the examples no longer work. The philosophy is still valid. I use it on JUnit Max, but because the tests are expensive to write and to run I don't have very many tests at that level.

 

I don't use a continuous integration environment, except insofar as JUnit Max is CI. Other than that I use the standard PDE tools. I structure my project as two plugins, one with the JUnit tests and the model code and the other with the PDE tests. That way Max doesn't try to run the PDE tests (in future I would like it to run them).

 

As far as designing Eclipse apps for testability, I twist the design so as much processing happens without Eclipse as possible. At times I have even gone so far as to have my own versions of things like input events, but that didn't payoff.

 

I wish you success in your development efforts.

He puesto en negrita algo que me parece muy relevante al caso que estamos tratando:

1) Kent Beck no tiene tests para todo lo que escribe. (Sí, un mito cayó cuando lo leí)

2) A veces no merece la pena estrujar el diseño sólo para que tu código sea testeable (automáticamente).

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com

2009/11/9 jorge <jorge...@gmail.com>

[Bob]

Asi lo dijo Kent otra vez durante una conferencia. 

El efecto fue enorme ;)

--

Bob - iPhone

[Abel Muiño Vizcaino]

También tiene una entrada sobre el tema en su blog.

http://www.threeriversinstitute.org/blog/?p=187

The second defect posed a dilemma. I could see how to fix the problem, but I estimated it would take me several hours to learn what was necessary to write an automated test. My solution: fix it and ship it. No test.

Parece un tipo pragmático, me cae bien :D

--

Abel Muiño - http://ramblingabout.wordpress.com/

[jorge]

demasiado delgada la línea entre *I estimated it would take me several hours* y *I estimated it would take me minutes*, no?

2009/11/9 Abel Muiño Vizcaino <amu...@gmail.com>

[Alberto Peña]

A ver, ¡que es Kent Beck! Yo necesito hacer tests para hacerlo bien (y como yo la mayoría).

Un saludo.

[Xavi Gost]

Vaya!!

Si lo dice el Kent Beck ........
Todos a hackear!!!

Pero vamos a ver!! TDD vs Pruebas Unitarias

Que no es lo mismo!! ni vale pa lo mismo!!

TDD es una tecnica para hacer emerger el diseño, no una tecnica de
Quality Assurance... que como resultado del TDD tienes una bateria de
test? Pues maravilloso no?? pero no es el objetivo.

Yo personalmente nunca puedo hacer codigo si no es TDD , simplemente
ya no se!! Forma parte de mi proceso de pensamiento que tiene como
resultado el codigo.

TDD merece la pena tires el codigo o no. No hay que tener demasiados
escrupulos en cuanto a testearlo todo por que tu objetivo es
evolucionar el diseño.
Yo intento alternar sesiones de avance del diseño donde relajo la
escrupulosidad del test sacrificandolo a que me conduzca mas rapido ,
con sesiones donde voy completando test, validando la solucion..(Es
fascinante como un diseño emergente que sale bien absorve todos los
test que vas completando con un minimo codigo)

Mi consejo: Usa TDD para todo, pero no lo pruebes todo.

Xavier Gost

[Mari Carmen Gutierrez De La Ossa]

El último mensaje de Xavi me ha resultado revelador. No se si era
capaz de distinguir una cosa de la otra, pero ciertamente TDD (el tema
de las siglas está muy bien, pero a veces nos hace olvidar el
significado real) nos habla de dirigir el diseño y posterior
desarrollo empleando tests. Lo cual nada tiene que ver con si queremos
que algo esté siendo probado o no, sólo que como resultado, además de
orientar y hacer sentir cómodos a los desarrolladores, nos regala unos
tests que nos vienen fenomenal.

Si tienes interiorizado el diseño emergente empleando tests, quizá no
tenga sentido preguntarse cuándo usarlo, sino cómo usarlo (más o menos
detalladamente). En mi caso no es así, y quizá por eso aún me cuesta
separar conceptos. Pero todo es ponerse :)

2009/11/10 Xavi Gost <xav...@gmail.com>:

[Éric Mignot]

Hum...

Hola!

Iba a vivir un nuevo dia fuera del foro (formo parte de aquellos que no tienen tiempo de leer todo ;-)) y boom el "nos habla de dirigir el diseño..." me da ganas seguir con el debate.

Yo, siendo ScrumMaster, veo también el TDD como algo que nos invita a compartir una definicion de "terminado" al nivel del codigo ;-). Es decir que por ejemplo nos llama a collaborar con el cliente (hablamos a veces de ATDD en este caso pero es el mismo concepto) para compartir lo que quiere decir terminar una historia, y de compartir lo en una prueba automatizada.

Como decia una tal Elizabeth durante el ultimo Agile tour en Grenoble : "TDD, que malo nombre"

a+

Eric

[jorge]

Esto invita claramente a una sesión multi sobre *cómo hago yo TDD* con un ejemplo real ;)

2009/11/10 Éric Mignot <emi...@pyxis-tech.com>

[José Manuel Beas]

¿Dónde y cómo? :-D

Un saludo,
Jose Manuel Beas

http://www.agile-spain.com
http://jmbeas.blogspot.com

2009/11/10 jorge <jorge...@gmail.com>

[jorge]

Por alusiones,

la próxima reunión ya está fijada en todos los sentidos y hay otros temas a continuación por prioridad. Como novato convocando reuniones, lo primero es saber si habría quorum de presentadores... Con dos o tres debería bastar ¿alguien?

Si lo hay, me animo a organizar algo aside :P

2009/11/10 José Manuel Beas <jose....@gmail.com>

[Juan Carlos Quijano Abad]

Buenos días,

¿cuando y donde? Es que acabo de llegar a la lista y no sabía que había convocada una reunión.

Muchas gracias

--
Un saludo
Juan Quijano

[Jorge Uriarte Aretxaga]

Muy buena, Xavi. Yo me pasé años diciendo a los programadores novatos que tenían que programar como si ellos fueran a usar ese código desde otro código, como si estuvieran haciendo "librerías", pero no conseguí transmitirlo nunca correctamente... hasta que encontré el modo en "haz un código que lo use, antes de hacerlo". Es decir, ni siquiera necesito que sea un test, ni siquiera que pase... pero a menudo, ponerse *fuera* del problema, como usuario del mismo, desvela el diseño adecuado. Y al fin y al cabo, qué es un caso de prueba sino un usuario de tu código?

_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte

2009/11/10 Xavi Gost <xav...@gmail.com>