articulo uncle bob en SA - TDD es para diseñar o para hacer pruebas automáticas ?

mailto:aleja...@autentia.com

jorge

no leída,

28 ene 2011, 6:58:1828/1/11

a agile...@googlegroups.com

Las pruebas manuales *siempre* hacen falta porque hay que *verlo*, *tocar* el producto de alguna forma. No puede ser que automaticemos todo (ejemplo extremo) y lo se ve es un churro enooooorme... Pero para eso están las demos ;)

Al menos en teoría, sería bueno tener una estrategia para tests de aceptación (selenium/webdriver) e integración.

Por cierto, alguien preguntó por webdriver/Selenium 2. Con mi experiencia de POC y conocimiento de la versión 1, es un salto de calidad notable en el que, para empezar, no hace falta poner timers para que cargue la página, puedes ejecutar tests sin browser y bueno... merece la pena el riesgo de ser usado sin tener una release *estable*.

2011/1/28 Gustavo Cebrian Garcia <g.cebria...@gmail.com>

Pregunta,

Alejandro Pérez García

no leída,

28 ene 2011, 7:13:1028/1/11

a agile...@googlegroups.com

Hola Juan Carlos,

recuerda que TDD como herramienta de diseño no es la única herramienta, es mejor si la combinas con otras. Si es mediocre o no es una valoración personal (hay a quien le gusta y a quien no), pero piensa que mediocre es mucho mejor que nada.

Cuidado también con confundir TDD con pruebas unitarias, que no es lo mismo. Es decir, puedes hacer Top-Down con TDD sin problema.

Cuando hablas de "problemas hiperacoplados" y de "refactorizar y refactorizar" entiendo que estás hablando de código que ya existe. En este caso TDD no te sirve porque llegas tarde. TDD es una herramienta de diseño, y este hay que hacerlo antes que el código ;)

Saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--

Alejandro Pérez García

Socio fundador de Autentia y www.adictosaltrabajo.com

(Desarrollo, Consultoría, Formación)

Tel.: 655 99 11 75

Autentia Real Business Solutions S.L.

"Soporte a Desarrollo"

http://www.autentia.com

Este mensaje, y en su caso cualquier fichero anexo al mismo, puede contener información confidencial y/o privilegiada, siendo para uso exclusivo del destinatario. Si Vd. no es el destinatario o lo ha recibido por error, por favor, informe inmediatamente al emisor y destrúyalo. Está estrictamente prohibido por la legislación vigente realizar sin autorización cualquier copia, revelación o distribución del contenido de este mensaje sin la autorización expresa del remitente. Las opiniones expresadas en este correo son las de su autor y no son, necesariamente, compartidas por Autentia Real Business Solutions S.L.

This e-mail, and in the case of any file annexed to it, may contain confidential and/or privileged information, and it is exclusively for the use of the addresses of the message. If you are not the intended recipient (or have received this e-mail in error), please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden by current legislation. The points of view expressed in this e-mail are solely those of the author and may not necessarily be from, or supported by, Autentia Real Business Solutions S.L.

Carlos Ble

no leída,

28 ene 2011, 7:23:2728/1/11

a agile...@googlegroups.com

Nosotros no tenemos bugtracker Gustavo, no lo necesitamos. Te parece suficiente? :-)
Logicamente tenemos bugs porque hay cosas que no se nos ocurren, pero nos basta
con 2 o 3 tarjetas kanban, normalmente no tenemos mas bugs que 2 o 3 a la vez.
Creo que es una calidad aplastante. Aparte de eso, cuando tenemos que hacer cambios los hacemos a toda leche y con toda seguridad.
No hay color :-)

Alfredo Casado

no leída,

28 ene 2011, 7:26:3928/1/11

a agile...@googlegroups.com

TDD es una herramienta para ir avanzando en pasos pequeñitos y seguros, al final de cada paso, que dura unos minutos, revisas que todo funciona desde varios punto sde vista:

- funciona correctamente.

- tu diseño tiene buena pinta.

La gracia es que cada muy poco tiempo tienes un feedback. Si lo pensáis un poco es lo mismo que hacer iteraciones frente a waterfall, pero a nivel pequeñito. En lugar de tirarte toda la mañana programando para probar al final, lo que haces es probar cada muy pocos minutos, es decir, hacer "iteraciones" más cortas.

Esta técnica sirve para diseñar cualquier cosa, top-down o downtown, da exactamente lo mismo. Por supuesto TDD "a ciegas" no sirve de mucho, quien diseña es el desarrollador no la técnica que use, ¿ recordáis lo de personas sobre procesos?, el proceso de TDD no asegura un buen diseño, un buen diseño lo asegura un buen desarrollador. Y el buen desarrollador elegirá los procesos que más le ayuden, personalmente TDD me ayuda muchísimo. Pero si alguien llega a buenos diseños por otros caminos, ¿quien soy yo para decir que lo esta mal por no usar TDD?

Luego están las pruebas automáticas, que son imprescindibles para poder construir y modificar un sistema con una red de seguridad, si haces TDD esas pruebas vienen de serie con tu técnica de diseño. Si no haces TDD pues luego tendrás que construir esas pruebas después. TDD como técnica de diseño es una elección, una que yo recomiendo, pero tener pruebas automáticas en mi opinión no lo es, en cuanto un sistema no es de juguete hacer todas las pruebas de regresión manualmente después de cada cambio es un gasto inaceptable de tiempo y personas implicadas.

es

Leo Antoli

no leída,

28 ene 2011, 7:53:5828/1/11

a agile...@googlegroups.com

¿ Entonces no estáis de acuerdo con el artículo en que la mayoría de ventajas que se mencionan son por usar pruebas automáticas más que por usar TDD ?

Saludos,

Leo

2011/1/28 Alfredo Casado <casado....@gmail.com>

Alfredo Casado

no leída,

28 ene 2011, 8:32:5628/1/11

a agile...@googlegroups.com

TDD es un proceso de desarrollo, el tio bob esta hablando de como medir la calidad del resultado final (número de test, cobertura...).

Otra cosa es como alcances esa calidad, si haces TDD es realmente fácil porque esa calidad forma parte de tu proceso, si no haces TDD también lo puedes conseguir, pero en mi opinión, es muchísimo más difícil porque la calidad es algo que agregas al final.

Juanjo Falcon

no leída,

29 ene 2011, 6:47:2829/1/11

a agile...@googlegroups.com

Lo importante para mi es la red de seguridad que te dan los tests automatizados. En mi caso la forma más efectiva de poder tenerlos es con TDD, por aquello de primero el test y luego el codigo. Si no lo hago así, y espero al final casi nunca tengo tiempo.

También me gusta porque involucra al desarrollador con la parte de QA continuo durante todo el proceso, y no lo deja para un equipo especifico al final del proceso al estilo waterfall.

Juanjo Falcon
http://jjfalcon.blogspot.com
http://twitter.com/jjfalcon

José Manuel Beas

no leída,

29 ene 2011, 9:45:1829/1/11

a agile-spain

Gracias, Leo. Interesante aportación. Voy muy retrasado en las lecturas (y en las prácticas, p.ej. @12meses12katas). El artículo de UncleBob empieza con un escenario que seguro que muchos habéis vivido en primera persona: el proyecto va bien usando Scrum hasta que el código malo vence al resto de buenas prácticas y entonces le echamos la culpa a... bueno, a lo que sea.

Creo que el artículo de UncleBob viene a recordar lo que se ha dicho tantas veces en este foro y en otros: que hacer Scrum olvidando las buenas prácticas de ingeniería que propone XP suele llevar al fracaso. Pero además me ha hecho replantearme lo de las métricas. Yo soy poco de medir, lo reconozco. Creo que antes que medir es necesario un cambio de mentalidad para ir adquiriendo buenas costumbres, o de lo contrario podemos caer (me atrevería a decir "caeremos") en empezar a hacernos trampas a nosotros mismos con tal de cumplir con las métricas. Pero como decía, el artículo de UncleBob me ha mostrado muchas buenas razones para medir.

We need to go fast, and we need to stay clean so we can keep going fast. How can we incent the team to achieve both goals? Simple. We measure both and reward them equally. If the team goes fast but makes a mess, then there is no reward. If the team stays clean but goes slow, then again, there is no reward. If the team goes fast and stays clean, then there is a reward!

We can measure messes by implementing engineering disciplines and practices like Test Driven Development (TDD), Continuous Integration, Pair Programming, Collective Ownership, and Refactoring; i.e. the engineering practices of eXtreme Programming (XP).

La práctica que más me ha llamado la atención que UncleBob propone medir es el tiempo de programación en pareja. Nunca me había planteado MEDIRLO, pero cuando lo he leido he pensado: "¡Claro! ¿Y por qué no? Si lo hacemos poco y creemos que debemos hacerlo más, ¿por qué no medirlo?". Pero mi yo anti-medir-por-medir me dice: "¿Realmente merece la pena medirlo? ¿No será una más de esas cosas que se mide pero que al final nadie hace caso al resultado de la medición?".

¿Mi opinión? Que medir cómo de bien hacemos las buenas prácticas es bueno: nos permite aprender de nuestros errores. Y éste es un excelente ejemplo. Si durante una retrospectiva (arqueológica, como decía Xavi Gost cuando trabajabamos juntos) vemos que desciende la calidad de los builds (número de veces que se ha roto el build) y eso es razón para analizar qué está ocurriendo, ¿cómo no lo va a ser un descenso en el número de horas que pasamos trabajando solos?

Un saludo,
Jose Manuel Beas

http://agilismo.es

http://jmbeas.iexpertos.com

http://twitter.com/jmbeas

Juan Carlos Quijano Abad

no leída,

29 ene 2011, 9:54:0729/1/11

a agile...@googlegroups.com

Buenas,

Vamos, en resúmen, que si se lo lees a UncleBob, le creas toda una teología y lo pones en el lado "bueno" del evangelio... :)

Estoy de acuerdo con lo que dice UnCleBob. Yo soy de la escuela de "Lo que no mides no puedes mejorarlo."

--

Un saludo

Juan Quijano

https://groups.google.com/group/agile-spain/browse_thread/thread/5474c261215c24fb?hl=es

Martin Perez

no leída,

29 ene 2011, 15:57:3829/1/11

a agile...@googlegroups.com

Hola Jose Manuel,

Estaría bien el enlace al artículo :)

Yo soy pro-medir. Cuanto más se pueda medir mejor. Lo malo es que al mismo tiempo necesitas muchos meses y muchos proyectos para sacar datos concluyentes. Si no, puedes ser como estos de los restaurantes que salen en la tele quejándose porque la semana anterior al entrar la ley anti-tabaco habían facturado 50€ más. Y perdón por el off-topic del ejemplo.

Me ha llamado la atención lo de la calidad de la build. No creo realmente que el número de veces que se rompa sea medir la calidad de la build. Una build sin casi tests o donde no crezcan los tests, será una build que apenas se rompa, y tendrá muy poca calidad. Al mismo tiempo, builds rotas puede significar que o bien nos cargamos el código, o bien que hemos aumentado el número de tests, y ambos casos son buenos síntomas (el primero detectamos bugs, bien!! , y el segundo es bastante obvio).

Pero bueno, creo que el objetivo de tu post no era entrar en estas dos chorradillas :) Me ha llamado la atención que has puesto en el subject diseño y TDD, y después no has escrito nada. Y yo que iba a entrar al trapo... :)

Saludos,

Martín

2011/1/29 Juan Carlos Quijano Abad <juancarl...@gmail.com>

--
Martín Pérez

Founder,
http://www.jobsket.com

José Manuel Beas

no leída,

29 ene 2011, 16:28:2229/1/11

a agile...@googlegroups.com

2011/1/29 Martin Perez <mpe...@gmail.com>

Hola Jose Manuel,

Estaría bien el enlace al artículo :)

Está al principio del hilo... http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

Yo soy pro-medir. Cuanto más se pueda medir mejor. Lo malo es que al mismo tiempo necesitas muchos meses y muchos proyectos para sacar datos concluyentes. Si no, puedes ser como estos de los restaurantes que salen en la tele quejándose porque la semana anterior al entrar la ley anti-tabaco habían facturado 50€ más. Y perdón por el off-topic del ejemplo.

Estoy contigo. Supongo que tiene que ver, de alguna manera, que sólo si tienes experiencia y, por tanto, criterio propio, estás en condiciones de sacar conclusiones de lo que mides. Parecido a cuando tienes que estimar una tarea/proyecto, que si tienes experiencia ya "te hueles" lo que va a pasar porque tienes una perspectiva. En esos casos es una especie de métrica cualitativa (¿oxímoron?) y subjetiva.

Me ha llamado la atención lo de la calidad de la build. No creo realmente que el número de veces que se rompa sea medir la calidad de la build. Una build sin casi tests o donde no crezcan los tests, será una build que apenas se rompa, y tendrá muy poca calidad. Al mismo tiempo, builds rotas puede significar que o bien nos cargamos el código, o bien que hemos aumentado el número de tests, y ambos casos son buenos síntomas (el primero detectamos bugs, bien!! , y el segundo es bastante obvio).

Hombre, es muy simplista mirar sólo el número de los builds rotos... sin más contexto. Idem para cualquier otra métrica. Por eso supongo que soy tan refractario al uso (ciego) de las métricas.

Pero bueno, creo que el objetivo de tu post no era entrar en estas dos chorradillas :) Me ha llamado la atención que has puesto en el subject diseño y TDD, y después no has escrito nada. Y yo que iba a entrar al trapo... :)

Creo que, efectivamente, no has visto el principio del hilo... :-)

Un abrazo,

JMB

Abel Muiño Vizcaino

no leída,

29 ene 2011, 18:26:4729/1/11

a agile...@googlegroups.com

Empiezo a pensar que a Uncle Bob le gusta mucho hacer símiles :-)

El 28/01/2011, a las 12:58, Juan Carlos Quijano Abad escribió:

El argumento es buenísimo: ¿Cómo hacen los contables para no equivocarse, que NO pueden? Apuntando DOS veces. Y pes una muy buena razón de utilizar TDD ya que te obliga, al hacer el test primero, que te asegures por duplicado que tu código funciona.

Hasta dónde yo sé, los contables están obligados a hacerlo así (por ley, no por precaución). Es como java que te obliga a declarar que, en "x = 1 + 2", la variable x es un entero. Le pones el tipo delante porque el compilador obliga.

Pero luego llega Scala y te permite obviarlo. Y ves que es bueno. Y luego te fijas que Ruby tiene un tirón impresionante y permite obviar todavía más cosas (paréntesis, por ejemplo). Y ves que es bueno. En otras palabras, "la moda actual" es prescindir de todo lo redundante para ser más efectivo.

Hacer las cosas dos veces "para estar seguro" (ciegamente, por "fé") no es un buen argumento.

Repetir trabajo es algo contra lo que estamos… (hace tiempo que nadie saca el tema del "waste", quizá ya no está de moda). Nos ganamos/pasamos la vida eliminando tareas repetitivas y reemplazándolas con sistemas automáticos.

Por otra parte, para probar 2 veces, en realidad haces dos implementaciones. Yo lo viví cuando Telefónica Móviles se "reincorporó" al grupo Telefónica y teníamos que verificar que sus métricas de calidad y las nuestras coincidían. Y me dicen que los bancos hacen lo mismo en ciertos sistemas.

Mi experiencia con TDD es "ambigua".

1.- Ahora me da "mal rollo" hacer un test después de escribir el código (probado manualmente) y que "pase", porque no sé si fallará cuando tenga que fallar. Así que muchas veces doy marcha atrás y "rompo" el código sólo para comprobarlo.

2.- Sigo sin acostumbrarme a basar mis diseños en pruebas de bajo nivel (que son las que me "salen" al hacer TDD… tengo la intuición de que BDD será más de mi agrado). Así que normalmente arranco los proyectos "a las bravas" y con pruebas manuales. Luego, a medida que el sistema se estabiliza, voy añadiendo tests para los bugs e incrementos. Y, al mismo tiempo, añadiendo tests para lo que ya existía.

Y ya, de forma no específica a TDD, con los tests (independientemente de que sean antes o después):

3.- Los tests que se acumulan son una "carga" para el mantenimiento (a equilibrar con la carga que es no tenerlos). No comparto la idea de que te permiten mantener la velocidad… lo que sí hacen es evitar que caiga en picado porque el sistema "se viene abajo".

4.- TDD y cambio de requisitos dan lugar a algunas pesadillas. Por ejemplo, los que hayáis hecho la kata del mes (string calculator), suponed que "el cliente" se da cuenta de lo absurdo que es usar una coma para sumar y os pide tener operadores y operaciones estándar (+, -, *, /). ¿cuántos de vuestros tests sobreviven?

Saludos!

--

Abel Muiño

http://abelmuino.es

Leo Antoli

no leída,

29 ene 2011, 19:59:2529/1/11

a agile...@googlegroups.com

Gracias por vuestras aportaciones. El artículo me ha parecido muy interesante y creo que va en la buena dirección juntando las prácticas de gestión con prácticas técnicas.

Se hablan de muchas cosas en él, a mi en el hilo lo que me interesaba particularmente era hablar de lo que dice de TDD.

Tampoco me ha parecido especialmente afortunada la comparación con el sistema de partida doble de contabilidad.

Por un lado está lo que ha dicho muy bien Abel.

Por otro lado, el sistema de partida doble no significa que se hacen las cosas dos veces, y que se haga como doble comprobación. Significa que siempre que hay un movimiento tiene que haber al menos una cuenta de la que sale el dinero y al menos una cuenta a la que va el dinero, y por tanto todos los movimientos tienen que tener cuentas de débito y crédito. Pero no hay necesariamente información duplicada, p.e. podrían ir 15 € de una cuenta a otras dos (10€ a una y 5€ a otra).

Lo único que te asegura este sistema es que el activo y pasivo+patrimonio serán siempre iguales, pero los contables pueden equivocarse en muchas cosas: en las cuentas a las que asignan el movimiento, cantidades, etc.

No se si con TDD podría pasar algo parecido, que diera una falsa apariencia de seguridad y se pensara que no necesitas hacer más pruebas de ningún otro tipo.

Alguien (de esta lista) decía que él hacía TDD y luego tiraba los tests del TDD y hacía las pruebas automáticas después de tener el código.

También en el artículo se dice que las pruebas automáticas deberían ejecutarse muy rápido. Estoy de acuerdo para las pruebas unitarias ya que tienen que ejecutarse continuamente, pero creo que también puede haber otras pruebas automáticas que tarden más tiempo y que sólo se ejecuten p.e. por las noches.

Saludos,

Leo

2011/1/30 Abel Muiño Vizcaino <amu...@gmail.com>

martin

no leída,

30 ene 2011, 2:25:0930/1/11

a agile-spain

Gracias Jose,

Mea culpa por no chequear el correo y no directamente el grupo. Como
tu mensaje parecía tan compacto y clarito (si no fuese por ese Hola
Leo del principio que me lo salté literalmente). Llevo unos días
bastante agitados y se ve que el mensaje original se coló como víctima
colateral en uno de esos borrados masivos.

Saludos.

On 29 ene, 22:28, José Manuel Beas <jose.m.b...@gmail.com> wrote:
> 2011/1/29 Martin Perez <mper...@gmail.com>

>
> > Hola Jose Manuel,
>
> > Estaría bien el enlace al artículo :)
>

> Está al principio del hilo...http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

> https://groups.google.com/group/agile-spain/browse_thread/thread/5474...
>
> <https://groups.google.com/group/agile-spain/browse_thread/thread/5474...>Un
> abrazo,
> JMB

martin

no leída,

30 ene 2011, 3:46:1230/1/11

a agile-spain

Gracias por el artículo Leo.

Mi opinión en general está a grosso modo en línea con lo que comenta
Abel. Lo de TDD es un tema curioso. Para mi es una técnica muy buena
cuyas principales virtudes son 1. te fuerza a hacer los tests y 2. te
fuerza a pensar antes de escribir, siendo esto último algo a lo que yo
creo que en esta profesión muchas veces se nos escapa y solemos
escribir y luego pensar.

Ya hablando de diseño, ahí dependerá de con quien hables.
Lamentablemente TDD es una técnica tradicionalmente muy asociada con
JUnit. Dejar que los tests de JUnit dirijan el diseño o arquitectura
de un sistema me parece una sobre-simplificación de un problema
bastante complejo e incluso de nuestra profesión. Es algo que funciona
para sistemas simples como clases aisladas, librerías pequeñas, etc.,
pero que no recomendaría para sistemas complejos. O dicho de otro
modo, una suite de tests de JUnit no garantiza otra cosa más que el
funcionamiento autónomo de un grupo de clases, su documentación
exhaustiva y aporta una garantía de mantenibilidad futura. Ahí es
nada, que no es moco de pavo. Pero no garantiza que el software
funcione.

Otra gente nos dirá que TDD se malinterpreta, que no tiene nada que
ver con unit tests, y que más bien hay que verlo como una técnica de
diseño de acuerdo a especificaciones (el test driven development vs
development driven testing). Me parece una definición más acertada y
yo me alineo mucho más en esto. BDD aparece entonces como lo
equivalente pero a alto nivel. Incluso habría que añadir los, casi
siempre pasados por alto en la literatura, tests de rendimiento a la
ecuación para garantizar que el sistema es usable de acuerdo a niveles
de servicio apropiados. Si juntamos BDD y ese PDD (¿Performance driven
design? ¿Hay algún acrónimo para esto?) sí que tenemos algo que
realmente puede dirijir el diseño y arquitectura de un sistema de
manera fiable. TDD tal y como mucha gente lo defiende no llega para
garantizar el funcionamiento de software complejo. Se queda en algo
que quizás se podría denominar microdiseño o microtesting.

Personalmente, yo intento practicar siempre TDD y dejo que influya en
mi diseño, pero mi diseño se rije más por especificaciones y
requisitos funcionales y no funcionales que exclusivamente por tests
de bajo nivel. No estoy seguro de la opinión de UncleBob al respecto
aunque creo que es reseñable el que en el artículo haya escrito "The
unit tests produced by TDD are documents that describe the low level
design of the system". No creo que ni "documents" ni "low level" estén
puestos al azar. ¿Es necesario el acuñar un nuevo término para una
verdadera metodología y no una técnica de tests? Es posible. BDD
estaría más cerca de ese término.

Respecto a la velocidad de las pruebas que comentas. Totalmente de
acuerdo. Creo que es el consenso general que las pruebas unitarias han
de ser muy rápidas, pero después se es mucho más permisivo con el
resto de pruebas de integración, funcionales, o de carga. Mi
experiencia al respecto es el haber dividido en subsistemas los tests
de integración para conseguir feedback rápido sobre el funcionamiento
de algunas partes que puedan ser más sensibles.

Saludos,
Martín

Juan Carlos Quijano Abad

no leída,

30 ene 2011, 4:04:0330/1/11

a agile...@googlegroups.com

Buenas,

Totálmente de acuerdo Martin.
Solamente una pregunta técnica, qué herramientas utilizas para Los test funcionales, de integración y de rendimiento?

--

Un saludo

Juan Quijano

Carlos Ble

no leída,

30 ene 2011, 5:37:2030/1/11

a agile...@googlegroups.com

Los que teneis esa sensacion ambigua con TDD, simplemente ni practicais TDD ni BDD regularmente :-)

Es cuestion de experiencia solamente. Practicar y practicar.

Abel Muiño Vizcaino

no leída,

30 ene 2011, 6:52:1830/1/11

a agile...@googlegroups.com

El 30/01/2011, a las 01:59, Leo Antoli escribió:

No se si con TDD podría pasar algo parecido, que diera una falsa apariencia de seguridad

Puede pasar y pasa :-)

Ayer estaba curioseando las implementaciones de las katas de http://12meses12katas.com. Elegidas 4 más o menos al azar, todas tienen agujeros, pero pasan los tests.

Por eso… http://bit.ly/eEMGoI

y se pensara que no necesitas hacer más pruebas de ningún otro tipo.

No creo que se llegue a abandonar otras pruebas. En todo caso, puede ser una buena pregunta para una entrevista de trabajo :-)

martin

no leída,

30 ene 2011, 7:40:4930/1/11

a agile-spain

Juan Carlos,

Yo soy de Java, Grails. Para tests de rendimiento siempre he usado
JMeter.

Tests funcionales. Pues depende de tus requisitos. Hay montones de
nombres, y muchos salen constántemente en esta lista. Hace más de
cinco años ya utilizabamos HP QuickTest Professional para que QA (8
personas) diseñasen sus tests de aceptación. Grababan scripts en el
Applet que era nuestra aplicación gracias a un mini-framework que les
hizo un compañero en VBS y los ejecutaban desde una Excel. Suena muy
"chungo" pero QA les encantó, cuando me fuí automatizaran el 75% de
sus casos, todo un logro para la empresa.

Por el medio Selenium y Canoo WebTest son las opciones. Siempre me
incliné más por el segundo por estar Selenium 1 muy atado con el
navegador. Pero ahora tendría que repasar Selenium 2 para recomendar
algo. Y también si eres más hardcore con HtmlUnit, por qué no. Hace
tres años en otra empresa creamos un sistema para que los QAs (30)
creasen sus propios tests con lenguaje natural, ya que no eran
programadores, y nos pudiesen dar caña, y que al mismo tiempo pudiesen
reproducir y replicar bugs fácilmente. Vamos, muy BDD. Mi experiencia
la expliqué en su momento en mi blog http://brigomp.blogspot.com/2010/03/la-horda-de-testers.html

Con Grails hay poco que hacer. Casi todo viene de serie. "Grails
Functional Testing" es una pasada, y otros que no puedo opinar son
"Grails Stories" o Spock.

Saludos.
Martín

On 30 ene, 10:04, Juan Carlos Quijano Abad

<juancarlosquij...@gmail.com> wrote:
> Buenas,
>
> Totálmente de acuerdo Martin.
> Solamente una pregunta técnica, qué herramientas utilizas para Los test
> funcionales, de integración y de rendimiento?
>
> --
> Un saludo
> Juan Quijano
>

> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
> Blog de opinión social <http://unmalnacido.blogspot.com/>
> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
> Blog de Tiro con Arco <http://litelllon.blogspot.com/>

> > agile-spain...@googlegroups.com<agile-spain%2Bunsubscribe@googlegr oups.com>

jcesarperez

no leída,

30 ene 2011, 10:09:0830/1/11

a agile-spain

Los tests no demuestran la ausencia de fallos, sólo sirven para
demostrar su presencia.

No creo que sea una cuestión de probar 2 veces -yo también pienso que
la metáfora no es muy afortunada-. Lo que te dan los tests es un grado
de confianza objetivo, o al menos más objetivo, que los que podemos
tener sin ellos. Porque sin tests, ¿qué confianza tienes en tu propio
código? Espera que hago unas pruebas manuales y te cuento... ¿Y en el
de tus compañeros? Idem. Por mucho que te aseguren que lo han probado.

Entonces, como dice Alfredo, esto al final se convierte en una perdida
de tiempo inaceptable. Sobre todo si usamos metodologías iterativas.
¿Qué confianza podemos tener en el código que se implementó hace 3-4
iteraciones? Espera que hago unas pruebas manuales y te cuento...

Por otro lado y respondiendo a Leo.

> ¿ TDD es principalmente para diseñar, para hacer pruebas automáticas, ... ?

Depende claro. Habrá casos donde te ayuden a sacar un diseño que no
tenías claro porque te pones directamente en el punto de vista del
usuario del api. Pero yo aquí estoy con Martin en que hay que intentar
dedicar un poco de tiempo a pensar antes de programar. TDD es Test-
First, pero aún es mejor hacer un poco de Think-First.

De todas formas TDD no es una bala de plata y en especial es muy
sensible a las ganas/habilidad/valentía de refactorizar de quien lo
practique. Aquí Alfredo lo ha explicado muy bien con lo de Personas
sobre Procesos.
Hace tiempo alguien en la lista puso una referencia a un pdf donde se
criticaba a TDD como herramienta de diseño para sistemas complejos,
pero no la encuentro.

> ¿ No se pueden hacer buenas pruebas automáticas,
> integración, sistemas, etc si no se hace TDD ?

Lo que te da TDD es que te obliga a pensar los casos de prueba antes
de programar. Luego también te obliga a implementarlos. Pero de nuevo
la clave está en el Think-First. En mi opinión.

> no se puede tener un buen
> diseño emergente si no se hace TDD ?

TDD ayuda, pero esa afirmación es muy taliban. Es más importante
dominar los principios y patrones de diseño básicos.

> Quiero decir, ¿ toda la parte de pruebas automáticas de la aplicación va en
> el TDD ?

Noooo. Al menos en mi caso. Muchos de nuestros tests son Test-Last, en
especial los tests funcionales (web son selenium y webservices con
soap-ui) y los de rendimiento.

Luego también están los tests que implementas como consecuencia de los
bugs que aparecen, ya sea en demos o en producción.
Por cierto, que en este punto no creo que, como dice Carlos Ble, tenga
nada que ver usar un BugTracker con usar TDD. El usar un BugTracker -
ojo, no un IssueManager- no es una cuestión de cuántos bugs tiene tu
código, sino de ayudarte a llevar mejor la gestión de incidencias con
el Usuario. No todas las incidencias son bugs.

Saludos,
Julio.

On 30 ene, 13:40, martin <mper...@gmail.com> wrote:
> Juan Carlos,
>
> Yo soy de Java, Grails. Para tests de rendimiento siempre he usado
> JMeter.
>
> Tests funcionales. Pues depende de tus requisitos. Hay montones de
> nombres, y muchos salen constántemente en esta lista. Hace más de
> cinco años ya utilizabamos HP QuickTest Professional para que QA (8
> personas) diseñasen sus tests de aceptación. Grababan scripts en el
> Applet que era nuestra aplicación gracias a un mini-framework que les
> hizo un compañero en VBS y los ejecutaban desde una Excel. Suena muy
> "chungo" pero QA les encantó, cuando me fuí automatizaran el 75% de
> sus casos, todo un logro para la empresa.
>
> Por el medio Selenium y Canoo WebTest son las opciones. Siempre me
> incliné más por el segundo por estar Selenium 1 muy atado con el
> navegador. Pero ahora tendría que repasar Selenium 2 para recomendar
> algo. Y también si eres más hardcore con HtmlUnit, por qué no. Hace
> tres años en otra empresa creamos un sistema para que los QAs (30)
> creasen sus propios tests con lenguaje natural, ya que no eran
> programadores, y nos pudiesen dar caña, y que al mismo tiempo pudiesen
> reproducir y replicar bugs fácilmente. Vamos, muy BDD. Mi experiencia

> la expliqué en su momento en mi bloghttp://brigomp.blogspot.com/2010/03/la-horda-de-testers.html

Marcin Gryszko

no leída,

30 ene 2011, 12:02:4230/1/11

a agile...@googlegroups.com

Respondiendo a Abel:

"Por otra parte, para probar 2 veces, en realidad haces dos implementaciones."

Si haces dos implementaciones, tienes que probar 4 veces. Expresandolo en la metáfora de Uncle Bob: "hacer dos implementaciones es contratar dos grupos de contables, cada uno siguiendo su metodología de contabilidad doble.".

"4.- TDD y cambio de requisitos dan lugar a algunas pesadillas. Por ejemplo, los que hayáis hecho la kata del mes (string calculator), suponed que "el cliente" se da cuenta de lo absurdo que es usar una coma para sumar y os pide tener operadores y operaciones estándar (+, -, *, /). ¿cuántos de vuestros tests sobreviven?"

Sobreviven los que tienen que sobrevivir. Las pruebas no es algo definitivo y monólitico. Los requisitos cambian, las pruebas también. La aplicación de TDD no te garantiza que tus pruebas sean mantenibles. En "xUnit Test Patterns" que trata sobre patrones de pruebas (con uno de los propósitos que es mantenibilidad) apenas se habla de TDD.

Saludos,

Marcin Gryszko

Abel Muiño Vizcaino

no leída,

30 ene 2011, 15:16:4230/1/11

a agile...@googlegroups.com

El 30/01/2011, a las 18:02, Marcin Gryszko escribió:

Respondiendo a Abel:

"Por otra parte, para probar 2 veces, en realidad haces dos implementaciones."

Si haces dos implementaciones, tienes que probar 4 veces. Expresandolo en la metáfora de Uncle Bob: "hacer dos implementaciones es contratar dos grupos de contables, cada uno siguiendo su metodología de contabilidad doble.".

Pero ya he dicho que no comparto esa metáfora :-).

Lo ha contando Leo, pero voy a insistir en ello… Cómo el dinero no se crea ni se destruye, sólo cambia de manos, al final se puede hacer la suma de dos formas y todo debe coincidir.

De forma simple, se trata de controlar el Activo (qué "dinero" puedo usar) y el Pasivo (a quién pertenece mi activo –por ejemplo, si es un préstamo o si son beneficios del año pasado–). Obviamente, al controlar ambas cosas, la suma de Activo debe ser igual a la suma del Pasivo.

Pero los contables no lo hacen para "testear" sus cuentas. Lo hacen porque necesitan la información vista desde ambas perspectivas. El activo no es un test para el pasivo ni al revés. Ambos datos son necesarios.

Por eso, *para mi*, el equivalente es tener dos implementaciones: SumarActivo y SumarPasivo. Y cada una de ellas, con sus tests.

"4.- TDD y cambio de requisitos dan lugar a algunas pesadillas. Por ejemplo, los que hayáis hecho la kata del mes (string calculator), suponed que "el cliente" se da cuenta de lo absurdo que es usar una coma para sumar y os pide tener operadores y operaciones estándar (+, -, *, /). ¿cuántos de vuestros tests sobreviven?"

Sobreviven los que tienen que sobrevivir. Las pruebas no es algo definitivo y monólitico. Los requisitos cambian, las pruebas también. La aplicación de TDD no te garantiza que tus pruebas sean mantenibles. En "xUnit Test Patterns" que trata sobre patrones de pruebas (con uno de los propósitos que es mantenibilidad) apenas se habla de TDD.

No lo enfoques como ataque a TDD (de hecho, el coste de mantenimiento de los test es algo a tener en cuenta siempre que hagas pruebas, sea con TDD o Test-Last o pruebas manuales o …).

Mi argumento va contra la idea de Uncle Bob de que TDD (i.e. tener muchas pruebas, altísima cobertura, etc…) mantiene la velocidad del equipo. No es verdad. Hay que hacer mantenimiento de los tests. Eso consume tiempo, la velocidad baja.

¿Que la velocidad baja menos que cuando no hay pruebas? Eso ya lo he dicho en mi primer mensaje de este hilo…

Y creo que está claro que todos preferimos "cargar" con el peso de las pruebas que con las consecuencias de no tenerlas… hasta cierto punto (cada cual tiene su límite, yo no busco 100% de cobertura).

Edu Rodríguez

no leída,

31 ene 2011, 1:10:5331/1/11

a agile...@googlegroups.com

> Mi argumento va contra la idea de Uncle Bob de que TDD (i.e. tener muchas pruebas, altísima cobertura, etc…) mantiene la

> velocidad del equipo. No es verdad. Hay que hacer mantenimiento de los tests. Eso consume tiempo, la velocidad baja.

Buenas, en mi opinión, TDD se centra en la calidad del código entregado. Trata sobre intentar mantener una velocidad y calidad constante. No solo velocidad. Puedes conseguir más velocidad obviando TDD pero yo ahora mismo no veo como conseguir más calidad en tu código fuente. Calidad, no significa % de cobertura, significa que tu aplicación haga lo que tiene que hacer, que los cambios sobre el código fuente se hagan con rapidez y con poca complicación, SOLID, no hayan duplicidades de código, las clases estén lo suficientemente desacopladas etc. Tampoco veo como dos personas diferentes pueden trabajar con la misma base de código con comodidad si no se respetan estos principios.

Esto es una apreciación personal: Si un desarrollador no sigue estos principios (SOLID), no escribe primero el código de prueba (asegura mantener las pruebas), ni refactoriza su código constantemente, está más vendido con TDD de lo que estaría sin hacer TDD. No se consigue la ansiada calidad y velocidad. En este escenario no tienes un problema con TDD por que los desarrolladores directamente no lo están aplicando. Tienes un problema con el desarrollador. Por suerte o por desgracia, ahora eres consciente de ello.

Que mantener todo eso puede convertirse en un infierno está claro. Nadie dijo que hacer buen código era fácil ni que todos estámos preparados para hacerlo. Muchos piensan que esto no es así y no dudan en meternos a programar aplicaciones que se venden por mucho dinero a gente que ni siquiera tenemos claros cuatro conceptos de OOP (no va por nadie en concreto). :-)

El viernes en la charleta que tuvimos en Barcelona sobre TDD todos coincidíamos en lo mismo (que alguien me desmienta esto si no es cierto): TDD no se puede imponer desde arriba, no se puede decir "Tú, ponte a hacer TDD" y esperar que todo funcione según el manualillo.

Por eso el discurso de esta gente siempre es "haz TDD, pero sobretodo practica". Por eso es una cuestión de actitud.

Quizá me he ido un poco por las ramas.

Un saludo

2011/1/30 Abel Muiño Vizcaino <amu...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com

Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--
Edu

jcesarperez

no leída,

31 ene 2011, 14:07:0631/1/11

a agile-spain

A veces parece que si no haces TDD tu proyecto está poco menos que
destinado al desastre. No estoy nada de acuerdo con eso, sin
desmerecer el plus que aporta utilizar *bien* TDD.

Tengo una pregunta: Si tuvieras que eliminar una de las siguientes
características de un desarrollador:

1 - Aplica decentemente los principios SOLID y patrones GRASP*.
2 - Escribe antes los tests que el código de la aplicación.
3 - Refactoriza su código sin temor si ve la necesidad.
4 - Integra su código con el de sus compañeros de forma contínua.
5 - Cumple la guía de estilos de codificación del equipo.
6 - Escribe código auto-documentado.

¿Cuál sería?
Supongamos que programa tests decentemente.

Saludos,
Julio.

* http://es.wikipedia.org/wiki/GRASP

On 31 ene, 07:10, Edu Rodríguez <dirtyaffa...@gmail.com> wrote:
> > Mi argumento va contra la idea de Uncle Bob de que TDD (i.e. tener muchas
>
> pruebas, altísima cobertura, etc…) mantiene la> velocidad del equipo. No es verdad. Hay que hacer mantenimiento de los
>
> tests. Eso consume tiempo, la velocidad baja.
>
> Buenas, en mi opinión, TDD se centra en la calidad del código entregado.
> Trata sobre intentar mantener una velocidad y calidad constante. No solo
> velocidad. Puedes conseguir más velocidad obviando TDD pero yo ahora mismo
> no veo como conseguir más calidad en tu código fuente. Calidad, no significa
> % de cobertura, significa que tu aplicación haga lo que tiene que hacer, que
> los cambios sobre el código fuente se hagan con rapidez y con poca
> complicación, SOLID, no hayan duplicidades de código, las clases estén lo
> suficientemente desacopladas etc. Tampoco veo como dos personas diferentes
> pueden trabajar con la misma base de código con comodidad si no se respetan
> estos principios.
>
> Esto es una apreciación personal: Si un desarrollador no sigue estos
> principios (SOLID), no escribe primero el código de prueba (asegura mantener
> las pruebas), ni refactoriza su código constantemente, está más vendido con
> TDD de lo que estaría sin hacer TDD. No se consigue la ansiada calidad y

> velocidad. *En este escenario no tienes un problema con TDD por que los

> desarrolladores directamente no lo están aplicando. Tienes un problema con
> el desarrollador. Por suerte o por desgracia, ahora eres consciente de ello.

> *

> > agile-spain...@googlegroups.com<agile-spain%2Bunsu...@googlegroups.com>

Edu Rodríguez

no leída,

31 ene 2011, 14:47:1031/1/11

a agile...@googlegroups.com

Sin duda alguna sería:

5 - Cumple la guía de estilos de codificación del equipo.

Y el motivo es por que:

6 - Escribe código auto-documentado.

Por lo que:

7- No necesita cumplir la guía de estilos. Su código es auto-documentado. :-)

Yo no digo que TDD sea la panacea. Pero sí que lo es comparado con la "metodología" más extendida de este país: El salto de mata.

Un saludo.

2011/1/31 jcesarperez <julio.cesar....@gmail.com>

--
Edu

Patricio Letelier

no leída,

1 feb 2011, 15:40:301/2/11

a agile...@googlegroups.com

Hola,

Lo mejor del artículo es la discusión que suscita :-), pero no pienso que era necesario leer dicho artículo para descubrir algo que para cualquiera que desarrolle software debe resultar obvio: "el mantenimiento existe", ... y bienvenido sea!!. Cualquier software que tenga éxito demandará mantenimiento. ... me explico a continuación.

Una metodología ágil es especialmente más apropiada en productos que empiezan desde cero (no estoy diciendo que sólo sirva para este caso). Además de todos los bien conocidos ingredientes favorables, tales como requisitos cambiantes, desafíos tecnológicos, oportunidad de negocio, etc., al principio como es natural, tu producto evoluciona rápidamente, y todo esfuerzo por intentar "tomar el control" especificando a fondo o estableciendo protocolos más estructurados puede quedar desbordado.

Pero el ritmo de incorporación de características en un producto software difícilmente se mantiene constante o al menos manteniendo la misma estrategia que usaste en su inicio. En la medida que tu arquitectura crece y se sofistica más esfuerzo conlleva el incorporar nuevas características o mejoras en las ya existentes. Más aún si tienes una base de usuarios/clientes utilizando tu producto No puedes correr el riesgo de sacrificar su confianza en tu producto por añadir cambios desafortunados, eso se paga caro.

Ahí viene la segunda parte, el TDD. En mi opinión se ensalza demasiado, otra nueva bala de plata, que con el tiempo ocupará el lugar que le corresponde: otra pieza útil o incluso imprescindible del puzzle, pero no la única. TDD se basa en la idea de no escribir código sin tener antes pruebas para probarlo. TDD se enmarca en el testeo unitario y está estrechamente ligado a automatización. Así pues, TDD contribuye a la programación y diseño a nivel unitario. Para pruebas de otros niveles, y en particular el que a mí me apasiona :-) (testeo de aceptación), TDD como tal, no los aborda (aunque existen ciertas extrapolaciones). Que alguien afirme que tiene miles de test unitarios automatizados no es para ponerle una medalla. Precisamente en el testeo unitario es donde mucha gente se "engolosina" en las infinitas instanciaciones que pueda tener una simple invocación de un método, pero la efectividad de las pruebas no tiene medida más aplastante que la asociada a responder a: ¿cuántos fallos pasan tus niveles de pruebas y llegan al cliente?. Añádele a esto la paradoja que escribir pruebas es también escribir código (de pruebas), que llegará a tener los mismos problemas de mantenimiento que el código fuente de tu producto :-).

Se pensará que estoy en contra de las pruebas y el TDD, pues no!, y rotundo no!, pero estoy convencido que hay que "dosificarse". En nuestros proyectos siempre privilegiamos la especificación (y puntual automatización "dosificada") de pruebas de aceptación. Considero que esta estrategia nos ha resultado rentable. TDD va incorporándose puntualmente en nuestras prácticas, pero el camino es lento, exige formación y cambio de chip para los programadores. El propósito no es el mismo, pero de momento, al menos con las pruebas de aceptación se intenta verificar la satisfactoria implementación de los requisitos, ... que no es poco dentro de todos los atributos de calidad que se pueden exigir a tu producto :-).

Un saludo,

Patricio Letelier

www.tuneupprocess.com

El 28 de enero de 2011 12:17, Leo Antoli <leo.a...@gmail.com> escribió:

Hola,
supongo que muchos habéis leido el artículo de Uncle Bob en la Scrum Alliance:

http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

Creo que ha sido muy inteligente por parte de la SA y en particular de su presidente Mike Cohn el hacer una serie de artículos técnicos, que encaja muy bien con Scrum que sólo trata la parte de gestión del proyecto.

A la mayoría de la gente que conozco le ha encantado el artículo, a mi me ha dejado un poco confuso con respecto a TDD.

La mayoría de ventajas que se mencionan de TDD en el artículo me parecen que son mejoras por usar pruebas automáticas, no TDD en particular.

No se si está pasando lo que pasa con Scrum, que muchas gente dice "Scrum" queriendo decir simplemente "hacer iteraciones", o "Kanban" queriendo decir "usar tablones" o "TDD" queriendo decir "hacer pruebas automáticas".

Yo uso TDD algunas veces, no para todo (a veces hago las pruebas automáticas antes que el código y a veces después). Lo que sí hago son pruebas automáticas, pequeñas iteraciones, diseño incremental, refactorizaciones, etc. No se si a eso se le está llamando TDD, aunque no siempre se haga el test primero.

P.e. para hacer la interfaz de usuario no creo que se haga un test que me pida que un texto tiene que tener cierto tipo de letra. Lo digo por llevar al extremo el que probablemente TDD (o xDD....) no se use para absolutamente todas las partes de una aplicación.

¿ Qué pensáis ? ¿ TDD es principalmente para diseñar, para hacer pruebas automáticas, ... ? ¿ No se pueden hacer buenas pruebas automáticas, integración, sistemas, etc si no se hace TDD ? no se puede tener un buen diseño emergente si no se hace TDD ? ...

¿ Los que hacéis TDD, luego no tenéis un equipo adicional de test (o si no otros miembros del equipo que no hayan desarrollado cierta funcionalidad) para que la prueben y hagan pruebas automáticas adicionales (de integración, end-2-end con Selenium o parecido, etc.) ?

Quiero decir, ¿ toda la parte de pruebas automáticas de la aplicación va en el TDD ?

Gracias.

Saludos,
Leo

--
Leo Antoli
http://twitter.com/lantoli
http://es.linkedin.com/in/lantoli

http://www.agileo.com

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--

Juan Carlos Quijano Abad

no leída,

2 feb 2011, 6:54:052/2/11

a agile...@googlegroups.com

Buenas,

Una vez más, bravo!!. Muy bien dicho. Consigues plasmar en palabras ideas con las que estoy totálmente de acuerdo y que me cuesta tanto transmitir.

--

Un saludo

Juan Quijano

jorge

no leída,

2 feb 2011, 8:11:422/2/11

a agile...@googlegroups.com

Patricio, te contesto en tus párrafos, en los que hablas de más cosas que TDD ;)

2011/2/1 Patricio Letelier <lete...@dsic.upv.es>

Hola,

Lo mejor del artículo es la discusión que suscita :-), pero no pienso que era necesario leer dicho artículo para descubrir algo que para cualquiera que desarrolle software debe resultar obvio: "el mantenimiento existe", ... y bienvenido sea!!. Cualquier software que tenga éxito demandará mantenimiento. ... me explico a continuación.

Te refieres a que después de lanzar/entregar un producto se sigue desarrollando funcionalidad? es evidente, no? Nunca me pasó algo diferente, la verdad.

Una metodología ágil es especialmente más apropiada en productos que empiezan desde cero (no estoy diciendo que sólo sirva para este caso). Además de todos los bien conocidos ingredientes favorables, tales como requisitos cambiantes, desafíos tecnológicos, oportunidad de negocio, etc., al principio como es natural, tu producto evoluciona rápidamente, y todo esfuerzo por intentar "tomar el control" especificando a fondo o estableciendo protocolos más estructurados puede quedar desbordado.

Esto es un gusto personal, supongo. Para mi, los requisitos siempre son cambiantes porque son complicados de conocer (IKIWISI) en productos nuevos y viejos. Los desafíos tecnológicos creo que pertenecen a otro ámbito de los proyectos, así como la oportunidad de negocio, con la que hay que estar alineada sí o sí, lo hagas como lo hagas.

Pero el ritmo de incorporación de características en un producto software difícilmente se mantiene constante o al menos manteniendo la misma estrategia que usaste en su inicio.

Me parece increíble que te plantees que un equipo va a usar la misma estrategia durante todo el proyecto... me dejas ojiplático. Espero que no sea así nunca, ni aún inconscientemente!!! Sería como avanzar el peón del rey todas las jugadas... o peor.

En la medida que tu arquitectura crece y se sofistica más esfuerzo conlleva el incorporar nuevas características o mejoras en las ya existentes. Más aún si tienes una base de usuarios/clientes utilizando tu producto No puedes correr el riesgo de sacrificar su confianza en tu producto por añadir cambios desafortunados, eso se paga caro.

Esto creo que lo hemos vivido todos y que se ha explicado ya incluso con referencias a históricos como fowler o el scrum flácido. Si no construyes con calidad, cada vez es más complicado hace cualquier cosa por muy bien que te organices o por muy alineado que estés. Es en ese caso cuando corres riesgos. Uno de ellos este del que hablas.

Ahora bien ¿qué pasa cuando tienes un ritmo sostenible, calidad notable, mejoras cada vez aunque sea un poco y sigues alineado? Espero que corramos muchos menos riesgos al añadir funcionalidad y que no aumenten los costes, que de eso estás hablando realmente, al *mantener* el software producido.

Ahí viene la segunda parte, el TDD. En mi opinión se ensalza demasiado, otra nueva bala de plata, que con el tiempo ocupará el lugar que le corresponde: otra pieza útil o incluso imprescindible del puzzle, pero no la única. TDD se basa en la idea de no escribir código sin tener antes pruebas para probarlo. TDD se enmarca en el testeo unitario y está estrechamente ligado a automatización. Así pues, TDD contribuye a la programación y diseño a nivel unitario. Para pruebas de otros niveles, y en particular el que a mí me apasiona :-) (testeo de aceptación), TDD como tal, no los aborda (aunque existen ciertas extrapolaciones). Que alguien afirme que tiene miles de test unitarios automatizados no es para ponerle una medalla. Precisamente en el testeo unitario es donde mucha gente se "engolosina" en las infinitas instanciaciones que pueda tener una simple invocación de un método, pero la efectividad de las pruebas no tiene medida más aplastante que la asociada a responder a: ¿cuántos fallos pasan tus niveles de pruebas y llegan al cliente?. Añádele a esto la paradoja que escribir pruebas es también escribir código (de pruebas), que llegará a tener los mismos problemas de mantenimiento que el código fuente de tu producto :-).

Bueno... defines y hablas de TDD según tu definición. La ampliamos un poquito? ;) TDD te puede ayudar a diseñar tu sw, ATDD a generar pruebas de aceptación en base a las condiciones de la US acordadas en el planning y sucesivos refinamientos, también contribuye a construir un set de pruebas que te ayuda a saber si un cambio afecta a otras partes del producto (trazabilidad en ejecución? ;) )... De todo esto se puede decir, como siempre, que kk se puede hacer con cualquier cosa, fíjate que hasta CR7 parece malo en el madrid ;) Quiero decir que escribir muchos tests no es un indicador de calidad pero escribir pocos igual sí que lo es y escribir malos tests te aseguro que lo es.

Por cierto, si separas código de test hablamos de mundos diferentes, no de TDD, en el que prima el desarrollo con ejemplos o muestras de la funcionalidad *antes* que la propia funcionalidad. A funcionalidad se le puede aplicar, otra vez, la granularidad que quieras: from unit to functional, por ejemplo.

En lo que sí estoy contigo es en que la mantenibilidad, que no el mantenimiento y que para mi es parte del desarrollo plano y llano (software funcionando en cada iteración), es un tema omnipresente sobre el que hay que prestar mucha atención desde el principio y que hila con *producir con calidad*.

Se pensará que estoy en contra de las pruebas y el TDD, pues no!, y rotundo no!, pero estoy convencido que hay que "dosificarse". En nuestros proyectos siempre privilegiamos la especificación (y puntual automatización "dosificada") de pruebas de aceptación. Considero que esta estrategia nos ha resultado rentable. TDD va incorporándose puntualmente en nuestras prácticas, pero el camino es lento, exige formación y cambio de chip para los programadores. El propósito no es el mismo, pero de momento, al menos con las pruebas de aceptación se intenta verificar la satisfactoria implementación de los requisitos, ... que no es poco dentro de todos los atributos de calidad que se pueden exigir a tu producto :-).

Lo mismo de antes... nada nuevo bajo el sol.

Patricio Letelier

no leída,

2 feb 2011, 14:26:162/2/11

a agile...@googlegroups.com

Hola,

Bueno, bueno, ... es que me has interpretado todo al revés :-). Asumo mi culpa por ser tan retórico :-). Además reconozco que el post me quedó demasiado largo. Lo positivo es que si me has interpretado al revés y me has criticado desde esa posición ... entiendo como consecuencia ... que estamos de acuerdo!! :-).

Bromas aparte (y honestamente, sin ánimo de ofender), hay una cuestión que me interesa muy especialmente. BDD y ATDD son precisamente esas "extrapolaciones" de TDD que no quise referenciar para no liar el tema. Efectivamente se trata de TDD llevado al ámbito de pruebas de aceptación. Aunque son propuestas interesantes, nuestra experiencia con ellas y las herramientas asociadas (FitNesse, JBehave y GrenPepper) no fue alentadora mirándolo desde una perspectiva de aplicación industrial. Ojo!, reconozco que sólo "jugamos" con ellas para la evaluación que necesitábamos en el artículo que estábamos preparando. Aún así pudimos concluir algunas deficiencias para nosotros claras en este sentido. En este link tenéis el artículo http://tuneup.dsic.upv.es/LinkClick.aspx?fileticket=Dshzxx-2qDY%3d&tabid=64&mid=416 . Además, no encontramos ninguna evidencia de utilización industrial de dichos enfoques. Si alguien tiene conocimiento de casos de éxito (o fracaso) con estos enfoques le estaría muy agradecido que nos lo proporcionara. Pero lo que busco es algo de primera mano, alguien que lo esté aplicando en sus desarrollos de productos.

Disculpadme por no crear un nuevo hilo, quizás sea lo más apropiado pero utilizaré la tonta excusa de que soy nuevo en el foro :-)... me arriesgaré a que etiqueten mis párrafos :-).

Un cordial saludo,

Patricio Letelier

www.tuneupprocess.com

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

--

Patricio Letelier

www.tuneupprocess.com

Juan Carlos Quijano Abad

no leída,

2 feb 2011, 16:52:552/2/11

a agile...@googlegroups.com

Buenas,

Esta semana he empezado a utilizar una herramienta de BDD que me está saliendo bastante buena, aunque tiene problemas de juventud. Se llama CodedUI y su hermano mayor el Test Panel parte del Test Service.

A ver si saco tiempo y hago alguna entrada en el blog. O más de una.

--

Un saludo

Juan Quijano