No más cursos de TDD

Estaba escribiendo una respuesta a un tweet en un hilo sobre developer testing y espontáneamente tuve esta revelación: no dictar más cursos de Test-Driven Development.
Si bien no lo tenía listado en mi catálogo de cursos, tenía un curso de TDD que venia dictando en forma privada a pedido de algunas empresas. Pero ya no más. La cuestión es simple: TDD es muy difícil de aplicar en proyectos de complejidad no trivial para gente que recién empieza con TDD y no creo que un curso de 1 o 2 días pueda bastar para que alguien aprenda la técnica y esté en condiciones de aplicarla en un proyecto no trivial apenas terminado el curso. Pero ojo, esto no significa que vaya a dejar de enseñar TDD. No, de ninguna manera. Simplemente voy a cambiar de estrategia: voy compartir gratuitamente un par de videos explicando la técnica (o incluso tal vez recomiende cursos de colegas) y luego ofreceré a los interesados trabajar conjuntamente en su proyecto para aplicar TDD.

Si bien yo uso TDD en mis proyectos, me llevó años y mucha perseverancia poder hacerlo una forma fluida y eficiente. Pero como he dicho más de una vez no considero TDD como una práctica de “efectividad universal”, a mi me resulta eficiente programar haciendo TDD, pero no significa que vaya a resultarle igual a todo el mundo. A mis alumnos les exijo que hagan TDD cuando programan para la materia porque es parte del plan de estudio. A mis compañeros de trabajo les sugiero que hagan TDD si es lo que hemos acordado como equipo, pero dependiendo del contexto me parece completamente válido que agreguen los tests a posteriori si no gustan hacer TDD.

Dicho esto, si quieren aprender TDD conmigo, no me consulten por cursos, contáctenme en privado y coordinemos directamente para hacer un par de sesiones de TDD sobre su proyecto.

Sobre la secuencia de tests al hacer TDD

Este es uno de los temas clave al hacer TDD. La elección de la secuencia de test puede hacer que el ciclo de TDD resulte muy fluido o que sea una pesadilla. Más aún, tengo la sospecha que la elección inapropiada de la secuencia de tests debe ser una de las principales razones de abandono de TDD. Personalmente suelo aplicar la heurística conocida como “TDD Guided by Zombies” propuesta por James Grenning, pero incluso usando esa heurística hay situaciones en la que mi secuencia de tests no me resulta lo suficientemente fluida. Quiero compartir un caso concreto para repasar distintas heurísticas.

Ayer por la tarde estábamos con otros 3 colegas en un sesión de mobbing trabajando sobre una funcionalidad que consistía en filtrar una lista de objetos Cuenta en base a 4 condiciones. En caso de no encontrar ningún objeto que cumpla con las 4 condiciones en forma simultánea debíamos generar un error pues eso representaba una situación excepcional de negocio.

Un colega propuso comenzar por los casos de excepción y luego los casos positivos. Lo que me gusta de esta heurística es que inicialmente permite avanzar rápido, el código del método generado comienza con una secuencia de validaciones que van respondiendo a los distintos casos de excepción. Lo que no gusta de esta secuencia es que durante varios ciclos el código no resuelve el problema para nadie, o sea, el método en cuestión solo valida y lanza excepciones pero no genera una lista filtrada. Hay que esperar casi hasta el final de la secuencia para obtener una lista filtrada. Una posible secuencia de tests con esta estrategia sería:

DeberiaLanzarExcepcionSiNoTieneCuentasEnPesos
DeberiaLanzarExcepcionSiNoTieneCuentasConTarjetaAsociada
DeberiaLanzarExcepcionSiNoTieneCuentasTitular
DeberiaLanzarExcepcionSiNoTieneCuentasActivas
DeberiaFiltrarLasCuentasEnPesosConTarjetaTitularidadActivas
...(otros casos positivos)...

Personalmente yo prefiero comenzar con casos positivos y dejar las situaciones de excepción para el final. En este sentido un camino posible sería arrancar literalmente al revés del ejemplo anterior, comenzando con el caso positivo que contempla todas las condiciones. El problema de esta estrategia es que genera un paso muy grande, o sea, implica escribir en un solo paso el algoritmo completo que considera las 4 condiciones.

Otra opción en línea con la idea de transitar el camino de casos positivos y siguiendo la heurística de Zombies, es arrancar con una condición positiva a la vez. De esta forma, ya de entrada estamos generando una lista filtrada, que al menos para algunos casos será una lista completamente válida. A partir de eso podemos ir generar nuevos casos positivos refinando el filtro y agregando los casos de excepción luego de tener todo el filtro completo. De esta forma cada paso del ciclo se mantiene pequeño y el algoritmo de filtrado se construye incrementalmente. La secuencia resultante podría ser:

DeberiaFiltrarSoloCuentasEnPesos
DeberiaFiltrarSoloCuentasConTarjeAsociada
DeberiaFiltrarSoloCuentasTitular
DeberiaFiltrarSoloCuentasActivas
.... (otros casos incluyendo los de excepcion)....

Obviamente que también está la posibilidad de tomar una secuencia que alterne casos positivos y negativos. De hecho si uno siguiera a raja tabla la heurística Zombie el primer caso (caso Zero) sería negativo y los siguientes positivos (caso One y casos Many).

Bueno, esto esto por ahora pero creo que este tema de la elección de la secuencia de tests aún da para mucha charla.

Materiales de la sesión TDD al banquillo

El viernes pasado estrené esta charla en el meetup online de Software Crafters Chile. La sesión duró poco más de 1 hora y yo quedé muy conforme. Creo que la exposición estuvo bien y la gente se mostró muy participativa. A partir de algunas preguntas/comentarios de los participantes se me ocurrieron algunos updates a la charla para una futura presentación.

Los slides que utilicé están disponibles aquí, allí mismo están las referencias a los papers formales sobre TDD. Como mencioné en la sesión, el paper que me resulta más relevante es el de Fucci, Erdogmus y colegas: “A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?

Para quienes quieran estudiar TDD mis recomendaciones son:

Agradezco a @JosephCastroR y demás organizadores del meetup por la invitación.

TDDeando la arquitectura

El viernes pasado estuve dando una charla titulada así en el contexto del meetup online de ArqConf.

Había más de 370 registrados pero como suele ocurrir con los meetups gratuitos, rara vez se llega al 50 %. Cuando comencé a hablar había alrededor de 120 personas y me consta que luego se fueron sumando más pero no tengo presente cuántos.

Dado que la charla trataría sobre TDD, comencé haciendo una breve encuesta a los presentes sobre su conocimiento de TDD. Si bien más del 90 % conocía TDD, tan solo el ~17 % dijo utilizarlo a diario. Personalmente no me sorprende, porque según estudios formales que hemos realizado en los últimos años, el uso consistente de TDD ronda el 20%.

La presentación fue grabada y está disponible en YouTube y los slides están disponibles aquí.

Estos son algunos de los libros en los que me basé para armar la charla:

  • Growing object-oriented software guided by tests, de Freeman
  • Designing Software Architectures: A Practical Approach, de Cervantes y Kazman
  • Just Enough Software Architecture: A Risk-driven Approach, de Fairbanks
  • Building Evolutionary Architectures: Support Constant Change, de Ford
  • Specification by example, de Adzic

Agradezco a Gus Brey y demás organizadores por la invitación.

Próximas charlas sobre TDD

En las próxima semanas voy a estar participando de eventos virtuales con dos nuevas charlas sobre TDD que vengo trabajando desde hace un tiempo. Aún no tengo confirmadas la fechas (en cuanto las tenga las compartiré en redes) pero igualmente comparto la temática de las mismas.

TDD al banquillo

Test-Driven Development (TDD) es una práctica creada por Kent Beck a finales de los 90. En 20 años ha cosechado varios practicantes, algunos “fanáticos” y algunos detractores. Definitivamente es una práctica muy conocida pero…¿cuan utilizada es? ¿cuanta gente usa TDD?.

Al mismo tiempo los practicantes de TDD hablan de un conjunto de beneficios que ellos mismo han obtenido, pero en términos formales/científicos ¿cuales son la mejoras que nos trae el uso de TDD?

TDD claramente impacta en la forma en que trabajamos, pero ¿tiene algún impacto en el resultado de nuestro trabajo? ¿el software resultante es “mayor calidad”?

TDD surgió en el contexto de Extreme Programming junto con otras prácticas como Integración Continua, Pair-Programming y Collective Ownership ¿es posible utilizar TDD en forma “aislada” sin incorporar estas otras prácticas? ¿Es igual de efectivo?¿Cuales serían los riesgos?

En la charla planeo recorrer todos estos interrogantes e intentaré darles respuestas desde la formalidad de varios estudios, libros y obviamente también con un condimento de experiencia personal. No es una charla introductoria a TDD en el sentido que no voy a detenerme a explicar en detalle cómo es la dinámica de TDD, creo que ya hay bastante de eso. La charla está dirigida a gente que ya conoce la propuesta de TDD independientemente de que la este usando o no.

TDDeando la arquitectura

Los cimientos de TDD se establecieron a finales de los años 90 en el contexto de Extreme Programming pero podríamos decir que, recién en 2002, Kent Beck formalizo la técnica en su libro Test-Driven Development by Example. En ese libro Kent explica la técnica y muestra ejemplos trabajando a nivel de prueba unitaria, haciendo TDD sobre clases. Sin embargo el mindset de TDD puede aplicarse a otros niveles de abstracción como el mismo Beck lo ha admitido. En esta charla veremos cómo utilizar TDD para guiar la construcción de una arquitectura en forma emergente. Esta charla no es charla introductoria a TDD, voy explicar muy brevemente la dinámica propuesta por TDD pero no será ese el foco. La charla está dirigida a gente que ya conoce la propuesta de TDD independientemente de que la este usando o no.

Investigación formal sobre TDD ¿queréis participar?

Hace unos dos meses comenzamos, con el grupo de Prácticas y Procesos de UNTreF, a trabajar en un estudio sobre Test-Driven Development (TDD).

TDD es un de las prácticas ágiles más populares pero comparativamente con otras prácticas ágiles es muy poco utilizada. Cuando digo que es popular me refiero a que es muy conocida (se sabe de que se trata) pero curiosamente hay varios estudios que muestran que su uso es mucho menor al de otras prácticas ágiles como las Restrospectivas e Integración continua. Dos fuentes que confirman esto son el reporte anual de VersionOne y nuestro propio estudio sobre Prácticas Agiles en Latam.

Con mi colega @dfontde tenemos la sospecha de que esta baja adopción de TDD puede deberse a issues de usabilidad de la práctica. Esto es precisamente lo que vamos a intentar probar (o descartar) en este estudio. Para ello utilizaremos el Modelo de Usabilidad de Práctica y Procesos que @dfontde está desarrollando como parte de su doctorado.

Para realizar esta investigación vamos a necesitar la colaboración de practicantes con al menos 5 años de experiencia en el uso de TDD. Los interesados pueden contactarme dejando un mensaje aquí.

Taller de TDD en UDAV

Ayer estuve haciendo mi Taller de Test-Driven Development en la Universidad Nacional de Avellaneda. Del taller participaron unos 15 alumnos de la carrera de Ingeniería Informática. Personalmente me gustó como salió y me sentí muy cómodo.

Agradezco a @jplagostena y @TefiMiguel por la haber habilitado esta oportunidad y por coordinación, impecable.

Comparto aquí algunas fotos y los materiales:

Notas del workshop de TCR

Ayer por la tarde/noche en la oficinas de Grupo Esfera hicimos un mini-taller exploratorio de test && commit || revert. Fuimos 9 participantes, todos practicantes de TDD. Comenzamos la sesión con un poco de contexto:

  • El código va con tests. No se discute.
  • Los tests pueden hacerse a priori o a posteriori. Podemos debatirlo.
  • TDD implica Test a priori pero Test a priori no implica TDD. Es definición.

En términos formales hay dudas sobre los beneficios de TDD

There’s no convincing evidence that TDD consistently fares better than any other development method, at least those methods that are iterative.

What Do We (Really) Know about Test-Driven Development?
(2018) I. Karac and B. Turhan, in IEEE Software, vol. 35, no. 4, pp. 81-85, July/August 2018. doi: 10.1109/MS.2018.2801554

Algunos autores sugieren que los beneficios de TDD no se deben al hecho de escribir los tests a priori sino al hecho de trabajar en pequeños incrementos:

The claimed benefits of TDD may not be due to its distinctive test-first dynamic, but rather due to the fact that TDD-like processes encourage fine-grained, steady steps that improve focus and flow.

A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?,
(2017) D. Fucci, H. Erdogmus, B. Turhan, M. Oivo and N. Juristo, in IEEE Transactions on Software Engineering, vol. 43, no. 7, pp. 597-614, 1 July 2017.doi: 10.1109/TSE.2016.2616877I.

Dicho todo nos propusimos probar la técnica TCR que propone trabajar en mini-incrementos. Pusimos entonces las manos en el teclado para resolver algunos ejercicios. Lamentablemente nos quedamos cortos de tiempo, pero acordemos agendar otro encuentro para seguir experimentando.

Les dejo un video del propio Beck haciendo un ejercicio al estilo TCR.

Finalmente les comparto aquí un video que hice mientras resolvía la Kata de Chopper que propuse hacer como primer ejercicio del workshop.

Notas de mi Taller de TDD en CONAIISI 2018

La semana pasada estuve en Mar del Plata participando del sexto Congreso Nacional de Ingeniería en Informática y Sistemas de Información. En ese contexto hice mi Taller Introductorio de Test-Driven Development.

Del taller participaron unas 15 personas de 7 universidades distintas. La evaluación general del taller fue 4.6/5.

Comparto aquí los materiales de estudio que recomendé a los participantes para profundizar en los temas vistos:

Agradezco a la organización del CONAIISI por haberme dado la posibilidad de dar este taller en el contexto de la conferencia.