TDD is dead. Long live teting ¿Qué opinan?

[Matias Mascazzini]

Hola,

me pasaron este articulo:

"TDD is Dead, long live testing" de el creador de Ruby on Rails.

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

¿Qué opinan al respecto?

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Carlos Ble]

Hola!
Como decimos por aca, yo opino que es un papa frita. Uncle Bob ya ha escrito en su blog al respecto aunque todavia no lo he leido. Debe ser unas risas :-)

--
Has recibido este mensaje porque estás suscrito al grupo "TDDev" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a tddev-sp+u...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a tdde...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/tddev-sp.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Pablo Escribano]

Siempre es bueno tener otras opiniones, el título de artículo es provocativo, me gusta como lo cuenta. Y en algunos aspecto comparto su punto de vista, pero no creo que TDD esté muerto, pero sí que tiene que evolucionar. ¿Carlos, tienes por ahí el enlace del artículo de Uncle Bob?

Gracias

Pablo Escribano - www.pabloescribano.net - twitter @PaulEcrivain

Coordinador de www.uxnug.es - twitter @uxnug_es

 

[Leo Antoli]

es esta la réplica de uncle bob:

http://blog.8thlight.com/uncle-bob/2014/04/25/MonogamousTDD.html

Saludos,

Leo

[Rafael Luque]

Por mi parte, prefiero el ensayo de James O'Coplien "Why Most Unit Testing is Waste" [1]. Me parece mucho mejor argumentado y coincido en el análisis de fondo.

En resumen, no creo que esté negando el valor de TDD, sino que señala que en muchas ocasiones las pruebas unitarias no se están enfocando correctamente y por lo tanto, no aportan valor e incluso pueden resultar contraproducentes. Mi experiencia personal confirma la tesis del ensayo. He visto equipos de desarrolladores abrazando las bondades del agilismo y que con las mejores intenciones escriben tests unitarios sin ningún sentido, como los que describe O'Coplien.

[1] http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

[JUAN PABLO OLGUIN]

Hola a todos, como siempre creo que Uncle Bob lo explica muy bien, mi unica critica es que creo que fue un poco injusto cuando habla de como comienza el articulo David H. Hanson, acerca  del fundamentalismo y lo que siure, porque me parece que David simplemente como decial alguien mas aqui de la lista, solo queria provocar...mucho para aumentar la llegada de su articulo  (aunque claro, todos sabemos que la palabra tiene connotaciones para nada felices). Segun mi opinion, desde ya.

Respecto al articulo de James O'Coplien....uff, dice algunas cosas con las que no estoy para nada de acuerdo como por ejemplo:

If you find your testers splitting up functions to support 

the testing process, you’re destroying your system 

Why Most Unit Testing is Waste 4 architecture and code comprehension along with it. Test at 

a coarser level of granularity

Pero dice otras cosas que estan muy bien, como cuando habla a veces los equipos tiene demasiados tests de unidad que no aportan realmente nada y se los deberia eliminar. El codigo de los tests de unidad si no sirven a su funcion es doble desperdicio.

Saludos!

[Angel Java Lopez]

Disculpen lo corto de mi comentario para un tema tan interesante.

Primero, recordar que estamos hablando de TDD y no de tests (unitarios o no). Segundo, TDD es un flujo de trabajo para crear codigo, donde los tests son solo una herramienta. Si se hace TDD, si se sigue el flujo de trabajo de TDD, no veo como hacer un test que no aporte valor, si esta orientado a explicitar una funcionalidad que necesitamos.

Y algo que creo esta vez @unclebobmartin no menciona (revisen, lei rapido): el flujo de TDD nos empuja hacia la simplicidad primero, evitando patternitis y frameworkitis de entrada ;-)

Nos leemos!

Angel "Java" Lopez

@ajlopez

[Maurício Aniche]

Hola,

Yo escribì sobre ello en mi blog. Está en portugués:
http://blog.caelum.com.br/mais-uma-vez-tdd-nao-e-bala-de-prata/

Regards,
Maurício
--
Maurício Aniche
www.caelum.com.br
www.alura.com.br
www.TDDNoMundoReal.com.br
www.aniche.com.br

[Alfredo Casado]

Personalmente me parece que DHH dice barbaridad tras barbaridad en su articulo, precisamente hay un movimiento bastante importante en la comunidad rails de gente que esta intentado cambiar las cosas y tirar hacia arquitecturas más modulares y menos acopladas porque no hay quien mantenga un app rails medianamente grande con el nivel de acoplamiento brutal al que se llega si uno sigue los consejos de DHH y el rails way.

Es más un problema de arquitectura que de hacer o no hacer TDD, lo que dice DHH es que en los test de tu lógica de negocio no hay problema en involucrar la base de datos, es más, que es bueno hacerlo para no complicarse la vida... Lo mismo con su propuesta de usar más test con capybara a nivel de browser. Lo que esta proponiendo hacer es caer directamente en el ice-cream cone: http://willhamill.com/2013/08/12/automated-testing-and-the-evils-of-ice-cream.

Test lentos, test fragiles, arquitecturas acopladas y sistemas que en cuanto empiezan a complicarse se vuelven completamente inmantenibles , en mi opinión a esto conduce lo que dice DHH, pero bueno, este hombre también decía que no veía ningún problema en enviar mails desde un controller utilizando una clase con métodos estáticos, no es precisamente un referente en cuanto a buenas practicas de arquitectura y testing este señor jeje.

Para publicar una entrada en este grupo, envía un correo electrónico a tdde...@googlegroups.com.

Visita este grupo en http://groups.google.com/group/tddev-sp.

Para obtener más opciones, visita https://groups.google.com/d/optout.

[Matias Mascazzini]

Muy interesantes sus respuestas. Por mi parte no tengo una opinión formada concluyente.

Pero cuando hablamos de pruebas unitarias, tal vez también haya que instruir a los programadores a como escribir mejores pruebas, para que estas aporten valor al componente que están probando. Históricamente fueron roles separados: programador, tester; pero este método de trabajo hace necesario un mezcla, una colaboración, sin que ningún de los roles desaparezca. Así como también los programadores se sobrecargaron de otras tareas para ser llamados desarrolladores, sin necesariamente los roles de otros especialistas desaparezcan.

// experiencia personal //

Estoy jugando con BDD/TDD en una aplicación Web usando herramientas como: Cucumber + Capybara (BDD), RSpec (TDD)

Y luego para la Integración Continua, sin que estos generé un gran sobrecarga de trabajo: GitHub, Travis-ci, Heroku

Si bien al principio tiene una sobrecarga de trabajo bastante grande, no se ven muchos avances (aquí es que hay que hacer lo que entendí propone Carlos en su libro, seguir realmente la metodología, todos sus aspectos, en todos sus pasos, aunque al principio moleste). Una vez que empiezas a entender como funciona el ciclo y que tienes que ir haciendo en cada paso, la cosa se pone más que interesante y esa sensación de seguridad para cambiar lo que quieres surge. Pero hay que tener la paciencia, constancia y decisión firme de continuar cuando todo parece "una perdida de tiempo, una sobrecarga". La integración continua viene siendo para mi algo muy practico y bonito, pero no podría ser posible, en mi caso, si no siguiese BDD/TDD por el esfuerzo extra que me generaría crear esas pruebas a posterior.
//--

Ahora lo mio es sin la presión de un Jefe o un PM que exige resultados en un tiempo concreto y ahí me imagino que es cuando la cosa cambia; cuando no podes alcanzar esos objetivos que antes alcanzabas en menos tiempo y cuando TDD deja de ser un opción para convertirse en una exigencia de la empresa/cliente ¿Será ahí cuando sugen las criticas?

Al final, para un viaje lo importante es saber que poner adentro de la valija y que dejar en casa. Lo que a mi entender debería de estar en claro de entrada es que este es un viaje de Agilismo entonces ¿Metemos o sacamos TDD de la valija?

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Angel Java Lopez]

Jeje... yo todavia tengo que encontrar un proyecto para produccion, con un dominio no trivial, que se tarde mas usando TDD que sin usar TDD ;-)

Tengo casos de terror, pero no publicos.

Cada vez que comparo, proyectos similares, mismo cliente, dominio parecido, el que esta escrito con TDD:

- es mas simple

- se tarda menos en crearlo

- es mas simple de detectar y corregir bugs

- tiene menos rate de bugs en produccion

- le cuesta MENOS DINERO al cliente final (menos tiempo del equipo de desarrollo, menos devolucion desde QA, menos tiempo de mantenimiento, menos tiempo de modificacion para nuevos requerimientos, etc)

- esta preparado para la version 2.0 y cambiar de equipo

- es mas facil cambiar decisiones, abrazando lo agil

El que no esta escrito con TDD... bueno, mejor ni quiero recordar ;-)

Recuerden, TDD no es para nosotros. Es para todos: nosotros, el equipo actual, el equipo que viene, y el cliente final.

Bueno, me llamo a recato, ya escribi bastante en mis posts.

Nos leemos!

Angel "Java" Lopez

@ajlopez

[Matias Mascazzini]

Gracias Angel por compartir desde tus experiencias laborales reales, es bueno leerte.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"

[Marcin Gryszko]

Justo iba a escribir sobre la visión de arquitectura según DHH - tu aplicacion es Rails y dejate de uncle-bobadas sobre la arquitectura limpia [1]. Si enfocas el sistema de esta manera es lógico que llegas a la conclusion que pruebas unitarias no te sirven para nada, porque en realidad no hay nada que testear con estas pruebas.

Otra cosa en el articulo es la definicion de la prueba unitaria:

"I rarely unit test in the traditional sense of the word, where all dependencies are mocked out"

Según DHH es la prueba de una clase (o quizás de un módulo de Ruby) con sus dependencias mockeadas.Últimamente hubo mucho movimiento en el tema de la re-definición de una prueba unitaria. Recomiendo la clasica charla de Ian Cooper "TDD, where did it all go wrong?" y el material acompañante del grupo de GOOS [2]. Resumiendo, una prueba unitaria es un test que verifica comportamiento importante para un stakeholder. No tiene que de una clase, puede ser de un grafo de objetos que implementan este comportamiento. Enfocando las pruebas unitarias así, se puede refactorizar cambiando la estructura interna sin romper las pruebas. Eso sí, para tener este tipo de pruebas, tu arquitectura tiene que facilitartelo - modelos reducidos y con puntos de integracion (entrada/salida) bien definidos.

Ultimamente es mi enfoque preferido y la verdad es que da mucho gusto tener pruebas enfocadas en unidades más grandes del codigo.

Marcin

[1] Tweet box en http://www.smashingboxes.com/domain-logic-in-rails/ 

[2] https://groups.google.com/forum/#!topic/growing-object-oriented-software/Hxp8cVfE4gI

[Angel Java Lopez]

Yo veo que siguiendo el flujo de TDD, y empujando siempre por la simplicidad, ni se necesita definir que es un test unitario o no.

Es decir, el test tiene que ser algo lo mas simple y que incremente la funcionalidad del sistema. Y lo que se escriba en el sistema, a partir de un nuevo test, tambien tiene que ser lo mas simple posible. A medida que el sistema va creciendo, el tener que el nuevo test incrementar la funcionalidad del sistema, puede que deje de ser tan simple como el primero. Pero no importa. Lo importante es el flujo de trabajo.

En alguna parte de la lista de GOOS, alguien recordo que Ken Beck se referia en el siglo pasado a "unitario" como "isolated", es decir, que se puede ejecutar en solitario, sin necesidad de ejecutar antes otros tests. Pero no tengo la referencia ahora.

Aca en Argentina, diria que no importa si el test es unitario o federal (viejas corrientes politicas del siglo XIX) o de color amarillo patito ;-). Me importa que agregue valor en el flujo de TDD. Luego, me importa si es lento o rapido. Pero primero que agregue valor.

Nos leemos!

Angel "Java" Lopez

@ajlopez

--

[Carlos Ble]

Hola!

Dejo aqui un post de Jose Armesto subre el tema:

http://blog.armesto.net/yo-no-soy-dhh-long-live-tdd

He comentado mi opinion en un comentario en este blog. A veces me cansa un poco leer "rants" de gente que se nota que NO sabe hacer TDD y le echa la culpa a la tecnica.

Muy interesante los comentarios :-)

--

Carlos Ble

www.CarlosBle.com - @carlosble 

Check out my latest app for team productivity: www.liveTeamApp.com

Author of the first book on TDD in Spanish: www.dirigidoPorTests.com/el-libro

[Jorge Muria]

Hola

Precisamente este fin de semana en Torrevieja en una de las charlas del Grupo de Usuario de .NET del Sureste (Gusenet) se habló sobre esto. Juan María Hernandez estuvo hablando de que no hay que "perder" más tiempo escribiendo tests que lo justamente necesario. Que los tests con mocks son muy complejos de entender y fragiles a cambios y refactorizaciones de código y que la pirámide de tipos de tests no tiene por qué ser una pirámide. Incluso mostró una cita de Kent Beck de que no le pagan por escribir tests sino código. ( http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests ) Este tipo de cosas puede desanimar facilmente a meterse en el mundo del test automático y el TDD al dar a pensar que es inutil. 

En mi equipo, lejos de tener el 80% de cobertura que recomiendan, tenemos un 40% y ya nos hace tener una calidad buenísima y con una cantidad de bugs de código muy pequeña. Y ese 40% no lo tenemos porque busquemos un 40, sino porque buscamos un 80 o un 100. 

Es facil desechar el TDD a la primera de cambio por su complejidad, a nosotros nos ha pasado varias veces, pero no por ello pensamos que no sea lo que hay que perseguir. 

Un saludo. 

[jua...@gmail.com]

Relellendo un post de Uncle Bob: http://blog.8thlight.com/uncle-bob/2014/03/28/The-Corruption-of-Agile.html parece que se adelantó a DHH.

Hay un parrafo que raya o sobrepasa la demagogia, depende ya de cada uno:

“Of course good software was built before TDD. Good software is being built today without TDD. So What? Those facts imply nothing at all about the effectiveness of TDD. After all, many doctors saved lives before the practice of sterile procedure, and many accountants managed to keep reasonable accounts before the practice of double entry bookkeeping. So what? Past success does not imply the ineffectiveness of new practices; nor does past success imply that the enthusiasm for new practices is inappropriate.”

Lejos de querer criticar a nadie, yo seguiré en mi día de la marmota particular intentando mejorar día a día.

La práctica personal me hace ver que TDD es una herramienta/técnica/magia que me ayuda a escribir un código cada vez mejor, no me importa la cobertura, solo me importa obtener el mejor código posible que puedo con las herramientas que tengo. Es decir, el código de producción, que es por lo que me pagan.

Y cuando alguien me pregunte en una revisión de código, le dire que lo he hecho con TDD, y si me dice el revisor que con SSJ se puede hacer mejor, aprenderé SSJ.

Seguramente hacer TDD para comprobar que un botón aparece con una animación de fadein en una aplicación de facturación no parece ser buena idea, no aporta valor, pero si estoy haciendo el motor de animaciones en donde eso sí aporta valor, sí haria TDD para esa funcionalidad.

Como parece que no estamos solos, parece que muy equivocados no estamos.

Pero joder, sí que es duro esto del TDD. 😉

My 2 cents.

Sent from my Casio watch

[Manuel Alonso]

Buenas , 

No sé porque se le hace tanto caso a este papanatas , ya con el titulo de su post lo que quiere es tener mas repercusión y protagonismo.  

Si en vez de seguir a este heroe creado por los rails members, se hiciera mas caso de por ejemplo Rich Hickey y sus pensamientos ,  como  

"Hammock Driven Development" : https://www.youtube.com/watch?v=f84n5oFoZBc

Que no va en contra de TDD si no todo lo contrario , aquí lo explica mejor que yo el tío Bob : http://blog.8thlight.com/uncle-bob/2011/10/20/Simple-Hickey.html , nos irian mejor las cosas

Saludos.

[JUAN PABLO OLGUIN]

Buenisimo los videos de Hickey, me gusto mucho este:  http://www.infoq.com/presentations/Simple-Made-Easy, gracias por compartir Manuel!!

[JJG]

Voy a intentar llevar un poquito la contraria ;)

Dejando a parte opiniones personales, que son estupendas pero irrebatibles, DHH hace algunos comentarios sobre TDD que comparto, pero no me parecen que sean motivo para abandonarlo sino para hacer mejora continua a ver cómo mejorar.

Comparto lo de que las pruebas no guían el diseño. Te ayudan a darte cuenta de si un diseño no funciona pero descubrir un buen diseño sigue siendo responsabilidad tuya. Por eso personalmente me gusta mucho la filosofía de refactorizar a patrones. 

Estoy muy de acuerdo con darle importancia a las pruebas del sistema y no creo que para eso haya que quitar TDD. .

DHH, dice que si aplicas TDD muy a rajatabla aumenta el nivel de indirección sin necesidad y tienes muchas pequeñas clases. Probablemente sea cierto y JB Rainseberg tiene algún artículo reciente en el que habla de este mismo tema.

Creo que DHH nos da pie a reflexionar y a mejorar. Un saludo.

PD: He citado a DHH de memoria, espero no haberme inventado nada.

[Carlos Ble]

Hola!

Aqui se puede leer a Kent Beck opinando al respecto:

https://m.facebook.com/notes/kent-beck/rip-tdd/750840194948847

Yo no podria expresarlo mejor :-)

[Pablo Bouzada]

Hola,

Uncle Bob ha vuelto a escribir sobre el tema:

http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html

es muy interesante el concepto de Humility (pienso que con doble sentido, dando una pequeña bofetada a DHH) al que se refiere en este post, y está relacionado con esto: http://xunitpatterns.com/Humble%20Object.html

Saludos,

Pablo

[Enrique Amodeo]

Hola a todos, creo que el artículo de Uncle Bob enlazado por Pablo resume bastante bien mi manera de pensar y viene muy a cuento. Pero para una vez que escribo en un thread, prefiero hacer un mail "provocador", y como no, verbose.

El señor DHH es muy inteligente sí, pero no olvidemos que su reputación se originó con Ruby on Rails, así que es normal que sea un defensor a muerte de los frameworks, en especial del suyo. Por lo tanto hay que leer entre lineas de su post (totalmente politicamente correcto) y ver que en realidad está defendiendo el enfoque, bastante tradicional, del "tu tira codigo con el framework, que después haremos unos test de UI automatizados...".

Sin ser un especialista en Rails, cuando intentas hacer TDD con él (como con cualquier framework), el framework pierde parte de su encanto. Ya no es tan conveniente usar la "magia" de Rails porque entonces puede ser que el código resultante sea difícil de dirigir por test. Por supuesto los buenos profesionales saben como combinar Rails con TDD de forma eficaz, pero los buenos profesionales son escasos y no cuentan desde el punto de vista del marketing viral (y todo framework famoso lo es, porque ha tenido un buen marketing viral).

IMHO pienso que DHH está simplemente predicando para la masa de desarrolladores que no podrían hacer software si les quitaran el Rails de las manos. Básicamente veo tres puntos en su discurso:

* ¿El TDD es problemático? No te preocupes, yo DHH, te digo que está muerto (pero te lo digo sin acritud, claro). Total, si yo no hago TDD es que no hace falta.

* Tu sigue usando Rails, y él te ayuda con su magia, y si quires haz test last con cucumber y capybara o similar.

* ¿Que quieres hacer código mantenible? Rails ya te pone el MVC de seríe con lo que el diseño ya está que te mueres y es super mantenible. A las malas refactorizas a la capa de servicios todo lo que no sea MVC y para adelante.

Conclusión: Probad a la manera de DHH y si os funciona, pues nada. Si teneis dudas, practicad y experimentar y sacad vuestras propias conclusiones. Yo ya he probado con TDD, sin TDD, sólo BDD, sólo test de sistema, etc y ya saqué hace tiempo mis propias conclusiones.

Salud !

Enrique

P.S. Que conste que comparto algunas cosas que dice, en especial que el excesivo énfasis y celo en test unitarios de componentes es tóxico.

P.S.S. Sí, Uncle Bob también arrima el ascua a su sardina, pero sus argumentos me convencen más que los de DHH.

[Iñaki Garcia]

Buenas a todos.

Yo pienso que alguien ha intentado darse bombo y lo ha conseguido, porque no paro de leer sobre este tema.

A lo largo de mi experiencia he obtenido muy buenos resultados trabajando con TDD. Pero entiendo que el éxito de un producto o un proyecto va mas lejos que la metodología, hay otros factores. Por eso opino que cada uno haga lo que mejores resultados le reporte.

Lo que puedo entender es que escueza leer este tipo de cosas porque nos ha costado plantar la semilla de las buenas prácticas pero darle mas bombo a este tipo de artículos es alimentar el propósito del autor, o eso pienso yo.

Feliz día del trabajador a todos.

[Carlos Ble]

Hola!

Aqui hay un post de respuesta (en mi opinion muy bueno) de Gary Bernhardt:

https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric?utm_content=buffere5fd7&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

Otro mas de Uncle Bob:

http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html

Buen dia :-)

[Pablo Bouzada]

Hola,

parece que, como prometieron, el próximo viernes 9 a las 17:00 (hora española peninsular) DHH se juntará con Martin Fowler y Ken Beck para hablar sobre su polémico post.

Aquí tenéis el link: https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k

Saludos,

Pablo

[Carlos Ble]

Gracias Pablo! :-)

[Matias Mascazzini]

Gracias a todos por sus repuestas a este tópico.

Saludos
Matías Mascazzini

Corrientes, Argentina

Me encuentras en:
LinkedIn: http://ar.linkedin.com/in/matiasmasca/es
Twitter: @matiasmasca
ComunidadTIC: @matiasmasca
---------
Le recomiendo visitar: www.ComunidadTIC.com.ar
"¿Eres Informático?"