Jose Armesto's Blog

Mis impresiones sobre el debate #isTDDDead

Fri, 23 May 2014 20:35:44 +0000

El debate sobre si TDD está muerto o no sigue vivito y coleando, y tras una guerra fría de artículos por ambas partes, ahora el intercambio de opiniones se ha pasado a un formato de vídeo debate donde Martin Fowler, Kent Beck y el mismísimo David Heinemeier Hansson hablan sobre el tema.

La verdad es que cuando anunciaron que Kent Beck iba a enfrentarse a David Heinemeier sobre el tema TDD, me alegré bastante por ver a gente tan buena en esto que hacemos debatiendo sobre distintas metodologías. “Seguro que aprendo de ambas partes“, pensaba yo.

Ingenuo de mí.

Tres hangouts despues, la idea general que para mí resume el debate es que DHH dice que TDD puede desencadenar en mal código. El problema fundamental que tiene su argumento es que esto no es exclusivo de TDD. Hacer TDD te puede llevar a un mal código de la misma manera que utilizar mal cualquier otra herramienta podría llevarnos por el mal camino.

Tests como herramientas de diseño

A veces parece que lo que no le gusta de TDD y de los tests unitarios, es que a diferencia de los tests de sistema que él prefiere, los unitarios son tests que no te ocultan los problemas que tiene tu código. No puedes crear un tests en aislamiento cuando tu clase tiene mil dependencias y no cumples cosas como la ley de Demeter o los principios SOLID. Sin embargo, los tests de sistema no se quejarán en absoluto. No son nada exigentes en ese sentido. A cambio, ¿qué pierdes? Pierdes feedback instantáneo sobre cómo de bien (o mal) estás diseñando algo. Pierdes velocidad en los tests que pasan de segundos a minutos.

Eligiendo el camino de los tests de sistema puede dar la impresión de que vamos más rápido porque tenemos que pensar menos los tests, pero lo que realmente estamos haciendo es esconder el polvo debajo de la alfombra. El problema es que llegará un día que la alfombra no será suficiente, y cuando nos queramos dar cuenta, las termitas han tomado el lugar.

Arquitectura Hexagonal

Otro argumento que me chocó de DHH, que menciona en el segundo hangout, es ese que dice que TDD penaliza el diseño porque tiendes a cosas como la arquitectura hexagonal. Para empezar, no entiendo qué relación tiene una cosa con la otra. Puedes hacer una arquitectura hexagonal sin hacer TDD y viceversa.

Además, dice que elegimos utilizar arquitectura hexagonal porque nos ayuda a crear tests. Que el principal motivo de este tipo de arquitectura es el testing.

En mi charla sobre arquitectura hexagonal (slides), no se mencionan los tests hasta la slide número 55 (son 60). Y lo que digo es que la facilidad de hacer tests con este tipo de arquitecturas, es un buenísimo efecto secundario que tendremos. Pero nunca se vende que sea el principal motivo. Cierto es que en el artículo original se hace más hincapié en los tests, pero para mí la principal ventaja es la independencia de herramientas: frameworks, bases de datos, etc,. además de promocionar al dominio a un sitio más visible y acorde a la importancia que tiene.

Conclusión

Me veré el último hangout, porque siempre se puede aprender algo de estas tres fieras, pero para mi, el debate no se ha llevado en ningún momento por cauces interesantes. Prefiero no pensarlo, pero ya van varias personas que mencionan que DHH solo pretendía hacer ruido. Espero que no fuese así.

El problema con el code coverage

Thu, 01 May 2014 13:27:28 +0000

Me he permitido el lujo de parafrasear a los maestros en el título de este artículo para hablaros de un tema algo polémico, por lo menos en los círculos en los que lo he hablado. Se trata de la necesidad de una alta cobertura de código, o code coverage.

El tema me lo recordó una serie de tweets que intercambiamos el otro día algunos en Twitter, hablando sobre la importancia de tener una cobertura de código del 100%. En el fondo todos estábamos de acuerdo en que no es importante tener un 100%, aunque no es la opinión más habitual que leerás por internet o escucharás en empresas. Mi opinión es que exigir cierto porcentaje de cobertura de código no es que no aporte nada, sino que es algo perjudicial.

.@SergiGP @theUniC Tener un porcentaje alto de code coverage es una consecuencia, no un objetivo. No hay que olvidarlo nunca.

— Jose Armesto (@fiunchinho) April 23, 2014

¿Qué es la cobertura de código?

La cobertura de código es una métrica que nos dice qué líneas de nuestro código ha sido ejecutado tras lanzar un test. De esta forma, yo puedo saber si hay partes de mi código que no están siendo testeadas. Este porcentaje se utiliza para medir la salud de un proyecto ya que si tiene un porcentaje bajo, podemos afirmar que hay muchas partes del código de las que no podemos estar seguros de si funcionan o no.

Una vez que sabemos qué es, la siguiente pregunta sale de forma natural.

¿Cuanta cobertura de código es necesaria?

Nótese el énfasis en la palabra “necesaria”. Y aquí es donde viene el problema. Muchos dirán que es una locura subir un código a producción que no llegue al 80% de cobertura. Otros te dirán incluso que 90%. Y siempre encontrarás al fanático que no programa ni el vídeo VHS y que dice que él no sube a producción nada que baje del 100%, porque es el porcentaje que obtiene al hacer siempre TDD.

Mi problema con todo esto es que los tests son una herramienta de confianza. Además de que me ayudan a conseguir un mejor diseño haciéndome pensar en el problema antes de pensar en la solución, me ayudan a detectar errores ejecutándolos después de cada refactorización. Esto hace que yo tenga toda la seguridad del mundo en refactorizar código: sé que siempre puedo lanzar los tests y ver si he roto algo. Es mi red de seguridad, mi chivato de errores. Entonces, ¿cuantos tests tengo que escribir? La respuesta es obvia: los tests necesarios para conseguir esa confianza. Los necesarios para decir, si están en verde es que todo está bien.

¿Cómo se mide esa confianza en un porcentaje de code coverage equivalente? No se puede. No se puede porque depende del código que estés haciendo. Si esa clase tiene un getter que lo único que hace es devolver una propiedad y nada más, no escribiré un test para ese método. Si ese otro método es complejo y posiblemente cambiará, créeme que lo testearé concienzudamente. La mejor metáfora que he visto sobre esto es la publicada en 2007, respondiendo a esta misma pregunta How much test coverage do you need?:

Early one morning, a programmer asked the great master:

“I am ready to write some unit tests. What code coverage should I aim for?”

The great master replied:

“Don’t worry about coverage, just write some good tests.”

The programmer smiled, bowed, and left.

…

Later that day, a second programmer asked the same question.

The great master pointed at a pot of boiling water and said:

“How many grains of rice should put in that pot?”

The programmer, looking puzzled, replied:

“How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.”

“Exactly,” said the great master.

The second programmer smiled, bowed, and left.

…

Toward the end of the day, a third programmer came and asked the same question about code coverage.

“Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table.

The third programmer smiled, bowed, and left.

…

After this last reply, a young apprentice approached the great master:

“Great master, today I overheard you answer the same question about code coverage with three different answers. Why?”

The great master stood up from his chair:

“Come get some fresh tea with me and let’s talk about it.”

After they filled their cups with smoking hot green tea, the great master began to answer:

“The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.”

“The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.”

“I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?”

The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down.

“The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.”

The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

Problemática

El problema de exigir un code coverage mínimo a los programadores, de proveer una respuesta simple a la pregunta, hace que el foco de los tests se centre en llegar a ese número mágico que nos hemos sacado de la manga, cuando el foco debería estar orientado a pensar qué tests son realmente importantes.

Una cobertura baja nos indica si un código está mal testeado, pero una alta no nos dice que un código esté bien testeado. De la misma forma que un test en rojo nos dice que hay un error, pero uno en verde no nos asegura la ausencia de errores.

La motivación para exigir un code coverage mínimo creo que sale de la necesidad de buscar respuesta a preguntas complejas del desarrollo de software. Centrándonos en llegar al mínimo de cobertura de código, puede hacer que un comportamiento del programa se nos escape e introduzcamos un bug en el sistema, porque estábamos demasiado ocupados escribiendo tests sin valor para pasar por las líneas que nos exigían.

Conclusión

Escribir tests es lo mejor que puedes hacer, y soy un gran defensor de utilizar TDD, pero como dijo Kent Beck en su famosísima respuesta de Stack Overflow:

Me pagan por escribir código que funciona, no tests.

Tener una alta de cobertura no es un objetivo a tener, sino que es una consecuencia de haber pensado bien en el problema que estamos solventando y en los comportamientos que son interesantes para testear. Los que no lo sean, no tenemos por qué testearlos.

Yo no soy DHH. Long live TDD

Thu, 24 Apr 2014 00:35:31 +0000

DHH es un gran programador, creador de algo como Rails, framework que quedará en la historia de la programación web. Hoy, él, ha sido noticia por escribir un post titulado “TDD is dead”.

Quizá DHH está en lo cierto diciendo que TDD es algo que está muerto, que es momento de seguir hacia adelante y dejarlo atrás. Como cuando crecemos y dejamos de utilizar los ruedines de la bicicleta: es algo para niños pequeños, pero de mayores ya no nos hacen falta. Quizá tiene razón.

Si eres lo suficientemente experto, entonces quizá ya no tiene sentido. Porque para mí TDD es eso: unos ruedines para programar que me ayudan a conseguir un mejor código. Si fuese capaz de escribir el mejor código posible a la primera, que siguiese los principios SOLID, que fuese auto explicativo, etc., entonces yo tampoco haría TDD. ¿Para qué molestarme?

Si me saliese a la primera, no necesitaría refactorizar muy frecuentemente y tener un unit testing que me avise cuando he roto algo. No me haría falta ese loop de feedback tan corto.

No todos somos DHH

El problema es que poca gente tiene la capacidad de hacerlo así de bien siempre. Sobre todo porque normalmente programamos cosas que nunca antes hemos programado. Si estoy haciendo algo que ya hice con anterioridad, quizá no es tan importante seguir un TDD estricto. Ahí tomaré atajos.

Pero si lo que estoy haciendo es completamente nuevo y no sé por donde atacarlo, créeme que haré TDD sin dudarlo, siguiendo todos y cada uno de los pasos.

Como la mayoría de la gente no tiene esa capacidad que decía antes, la metedura de pata del post de DHH me parece mayúscula. Me lo parece porque no solo dice que TDD no es para él, sino que anima a la gente a no utilizarlo, y deja entrever que hará cambios en rails para animar a la gente a hacer menos unit testings y más tests de otro tipo.

Teniendo en cuenta su posición de lider en la comunidad, me parece una temeridad por su parte. Está invitando a la gente a que rompa algo tan establecido y aprobado como la pirámide de testing, basándose en que no han sido tests útiles para testear aplicaciones basadas en rails. Un vistazo rápido a las charlas de las conferencias de Ruby de los últimos años y vemos como hay un tema recurrente en todas ellas: cómo escapar de Rails. Bien sea por hacer tests más rápidos y tener feedback antes; o porque los modelos de mi aplicación no estén entre mezclados con el sistema de persistencia; o porque quiero tener arquitecturas que me permitan intercambiar componentes fácilmente.

Siempre lo que se busca es escapar de Rails, minimizar la dependencia con el framework. Los unit testings son costosos de hacer cuando el framework está en el medio. Por eso no le han sido útiles: porque su framework no permitía que lo fuesen. La solución, obviamente, no es dejar de hacerlos, sino arreglar el framework.

Sit-ups are dead. They don’t work when I eat all this sugar and take on all this severe stress. Long live gastric bypass surgery.

— ☕ J. B. Rainsberger (@jbrains) April 23, 2014

El Dogma

De todas formas sí que comparto con él una cosa, y es el nivel de dogma que TDD ha alcanzado en los últimos años. Personas como Uncle Bob, cuando hablan de TDD, se ponen una sotana encima para predicar la palabra sagrada. Uncle Bob ha sido capaz de convertir la práctica de TDD en una religión.

Uncle Bob, el predicador de Texas

Es una religión porque al igual que las religiones, el TDD de Uncle Bob promete la salvación eterna si cumples con los mandamientos (3 en el caso del TDD). Pero no solo eso, sino que también asegura el castigo eterno para aquellos que no lo hagan. Eso es lo que hace cuando alude al poco profesionalismo de la gente que no lo practica. Está señalando a los herejes.

En mi opinión, hacer TDD es una herramienta más. Una herramienta casi imprescindible para mi, pero una herramienta al fin y al cabo. A alguien que utilizase el bloc de notas para programar le recomendaría que probase Sublime o PHPStorm. Al igual que le recomendaría TDD si no lo utiliza. En ambos casos creo que esa persona será más productiva y hará mejor código. Por tanto será un programador más rentable. ¿Quiere decir esto que no se puede ser rentable si no se usa TDD? Claro que no, al igual que también puedes ser un crack en el bloc de notas.

Los defensores de TDD también debemos hacer auto-crítica y pensar en si la forma que elegimos para comunicar las bondades de TDD es la más correcta.

Conclusión

Para mi su post de hoy ha sido una gran metedura de pata. Los unit testings aportan muchísimo valor a la hora de detectar errores, y el TDD es una de las mejores herramientas para que nuestro diseño sea mejor.

Yo no soy DHH. No he inventado Rails ni soy el CTO de una gran compañía. Yo seguiré utilizando TDD para que me ayude a hacer el mejor código posible.

Sin refactoring no es TDD

Fri, 11 Oct 2013 17:57:56 +0000

Parece evidente, ¿verdad? Cuando explicas TDD (Test Driven Development), explicas que tiene 3 fases: rojo, verde y refactoring. Sin embargo, parece que son las 2 primeras las que entran con mayor facilidad en la mente del programador.

Presentas la kata y allí van disparados a escribir su primer test para estar en rojo. Una vez allí, _baby step_ en el código con lo mínimo indispensable para pasar el test y ponernos en verde. Es entonces cuando deberíamos pensar en el refactoring, pero normalmente es difícil encontrar cosas a refactorizar en nuestro (poquito) código en las primeras iteraciones, así que pasamos a rojo otra vez escribiendo un nuevo test.

Este proceso se repite de forma rápida durante los primeros tests, y con la excusa de que con pocos tests es difícil encontrar duplicaciones o cosas a mejorar en el código que hace pasar estos tests, poco a poco entramos en el modo semárofo del rojo-verde.

Los más aventajados del lugar se aventuran a mejorar alguna cosilla cuando están en verde, pero suele ser algún cambio pequeño sin importancia, mientras la casuística de if’s y else’s sigue creciendo sin que nadie haga nada por evitarlo. Se olvidan los principios SOLID, como si fuesen principios teóricos que poco o nada tienen que ver con la práctica. “La teoría no es lo mío, yo soy más práctico”: ¿os suena?

Como facilitador, solo te queda realizar las preguntas adecuadas:

¿si quiero ampliar el funcionamiento con una nueva regla de negocio, tendré que cambiar mi clase? ¿cómo de costoso será el cambio?
¿está ese comportamiento bien encapsulado? ¿hay suficiente abstracción?
¿hace esta clase una y solo una cosa?

Es sobretodo con la primera pregunta con la que la gente se da cuenta de los problemas de su diseño actual, quizá porque es la pregunta más “práctica”, por así decirlo. En el fondo son los mismos principios, pero forzando a la gente a pensar en un caso práctico, por ejemplo dando tú mismo nuevas e imprevistas reglas de negocio, la gente entiende por qué es mejor seguir SOLID.

Estas preguntas hay que realizarlas desde muy temprano. Si la gente va posponiendo el refactoring, cada vez es más difícil cambiar el diseño actual porque cada vez habrá más reglas de negocio en el código, y cada vez habrá más tests que quizá haya que retocar, si el refactoring más que un simple refactoring.

También se tiende a olvidar que en ese momento tenemos un conocimiento grande del dominio, y podemos plasmar las reglas del dominio de una forma que ahora entendemos, pero quizá no entendamos en el futuro. Justo ahora es el mejor momento para dar nombres que expresen la intención del código. Por ejemplo: introducir condiciones en métodos o variables con nombres expresivos.

Una de las grandes ventajas del TDD, es que el refactoring está dentro del ciclo de desarrollo. Si no lo hacemos frecuentemente, se pierde el efecto.

Sin refactoring no es TDD.