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.

Taller de TDD (gratuito para estudiantes)

En nuestro proyecto de investigación en UNTREF trabajamos en el estudio de prácticas y procesos de desarrollo. En ese contexto hemos armado un taller prácticas de desarrollo ágiles enfocado en Test-Driven Development, Continuous Integration y Pair-Programming. El siguiente video explica brevemente la dinámica de taller.

Si hay alguna universidad que esté interesada en realizar este taller en sus instalaciones solo tienen que ponerse en contacto conmigo.

Taller de TDD, CI & Pair-Programming

En el contexto de las Jornadas de Ingeniería de Software del Uruguay, estuve haciendo un Taller sobre Test-Driven Development, Continuous Integration & Pair-Programming.

Participaron del taller unas 19 personas y a pesar de algunos imprevistos (como que la gente no hubiera leído los materiales de preparación), el taller salió muy bien. La evaluación general del taller fue 4.4 / 5.

Dejo aquí los recursos que compartí con los asistentes del taller:

Primeras Jornadas de Ingeniería de Software del Uruguay

Los días 16 y 17 de Octubre se realizarán en Uruguay las Primeras Jornadas de Ingeniería de Software y tengo el honor de haber sido invitado como orador.

En ese contexto estaré hablando sobre unos de los temas “calientes” de la actualidad: DevOps. Concretamente el título de mi disertación será “DevOps, myths and facts of a new paradigm“. También estaré dando un taller enfocado en Test-Driven Development, Continuous Integration y Pair-Programming.

Las jornadas son de entrada libre y gratuita pero es necesario registrarse. Pueden encontrar más información en la página del evento y siguiendo la cuenta oficial de twitter.

Ejercicio: interpretación de métricas de test y cobertura

Amo las métricas, creo que es un efecto colateral de la búsqueda de la mejora continua. Para mejorar es necesario medir, pero con medir no basta, hay que saber qué medir y luego hay que interpretar lo medido para poder accionar al respecto.

Hoy quiero compartir un actividad que hicimos esta semana con mis alumnos de Ingeniería de software en UNTreF. La dinámica fue simple, dado un proyecto tomamos los gráficos de evolución de tests y cobertura generados por Jenkins y los analizamos para generar hipótesis a partir de ellos. Invito a los lectores a sumarse a este ejercicio, analicen los gráficos e intenten extraer información de ellos. Comparto un poco de contexto que les puede resultar útil para el análisis: el proyecto en cuestión es un modelo (o sea pura lógica, sin UI ni base de datos), los desarrolladores son alumnos universitarios que tenían que trabajar con 2 consignas:

  1. Hacer el desarrollo usando TDD
  2. Hacer integración commiteando al repositorio central (en el mainline) luego de cada nuevo test verde.
  3. Si el build se rompe, se para la línea hasta que sea arreglado

analisis_1

Aquí va mi análisis y con mis hipótesis/conclusiones (=>):

  • En el build #10 se agregaron 10 tests => no respetaron la consigna 2
  • Pero a pesar del agregado de tests la cobertura disminuyó => posiblemente por el agregado de código de dominio sin los correspondientes tests => violación de la consigna 1
  • En los siguientes builds (#11,#12 y #13) la cantidad de test aumenta de a uno y también se evidencia un aumento en la cobertura.
  • En los builds #14 y #15 se evidencian nuevamente saltos grandes en la cantidad de tests y de la mano de ello también un aumento de la cobertura.
  • Entre los builds #15 y #18 la cantidad de tests se mantiene constante y lo mismo ocurre con la cobertura => esto podría indicar pasos de refactoring.
  • En el build #19 disminuye la cantidad de tests y con ello la cobertura => esto podría deberse a un cambio en el código de dominio que no fue acompañado completamente por la correspondiente actualización de test.
  • Finalmente la cantidad de tests se mantiene constante en los últimos builds pero la cobertura disminuye => me hace pensar en agregado de código sin los correspondientes tests.

¿algo que agregar?