Reflexionando sobre el Testing, en modelos Ágiles… pero con la realidad del código legacy

En el mundo ideal, en happylandia, no se tira una línea de código sin un Test unitario, el TDD (las 3 reglas del TDD) está inmerso en la cultura, hay un montón de pruebas unitarias, muchas más que de integración y, por supuesto, muchas más que de las automatizadas frente a la interfaz gráfica.

Porque, en el mundo feliz (que no irreal o teórico), el diseño posibilita el testing unitario de verdad (no el que se disfraza de test de integración).

Pero el mundo real es más oscuro, siniestro y triste, el mundo real está asolado por Walking Deads, por código legacy (así se le llama al software viejuno que no destaca por haber sido brillantemente programado y que toca, y tocará, mantener muchos años) muy mal diseñado, con gran cantidad de «bad smells«, que lleva ahí desde la prehistoria y que seguirá ahí muchos miles de años más.

Yo, que llevo ya unos cuantos años en esto, no he conocido ningún final feliz cuando una empresa se ha lanzado a volver a hacer de nuevo un sistema grande para quitarse el legacy (los habrá, pero yo no los he visto). Hasta el tío Bob le dedicaba uno de sus vídeos a lo poco exitoso y riesgoso que es plantearse volver a hacer de nuevo un software grande que está en producción.

Así que muchos de nosotros vivimos, y viviremos, intentando aplicar buenas prácticas, Ágiles, o no Ágiles, buenas prácticas técnicas… con código legacy plagado de Walking Deads. Eso es así y va a seguir siéndolo mucho tiempo.

El legacy malo, y lo que limita para aplicar prácticas Ágiles da para mucho hablar, y de todo lo que implica… hoy quería escribir sobre el Testing.

Quería escribir sobre el Testing porque nos hace mucho daño, porque cuando no hay un Testing mínimamente digno… nos llegan muchos bugs de cosas que se suponía que se habían terminado hace varios Sprints (por centrarme en los bugs y el desperdicio que suponen, porque las carencias en Testing implican muchas más cosas).

Y esos bugs, que vuelven Sprints después, tienen mucho impacto, porque son desperdicio puro, y generan mucho trabajo superfluo, en términos Lean, separan mucho el tiempo desde que se empezó a hacer algo hasta que realmente se termina y añaden muchos tiempos de espera.

Sin dejar de lado que, aun con legacy, hay que refactorizar de manera frecuente, en cada Sprint, que continuamente hay que eliminar deuda técnica (recuerda, ciclo de vida iterativo e incremental), etc., también es cierto que cuando tenemos un legacy muy grande (y muy Walking Dead) no es realista imaginar que la cobertura de test unitarios vaya a ser la que nos gustaría.

En vez de torturarte mentalmente con cómo deberían haber sido las cosas, cómo te gustarían o plantear cosas irrealizables (como tirar un software gordo y hacerlo de cero), plantea estrategias de guerrilla y supervivencia, para optimizar cada minuto que inviertas en mejorar.

Por ejemplo, sé inteligente, ya que no puedes tener todas las pruebas que te gustaría, analiza detalladamente cada bug que llega y, entonces, piensa que tipo de testing, realista, realizable, podría haber evitado ese bug.

Piensa si lo mejor hubiera sido de integración, unitario, etc., pero sobre todo piensa la opción con mejor ROI (retorno de inversión, lo que logro en función del tiempo invierto).

En vez de meterte en refactorizaciones idílicas, o sin estrategia, u orientadas por ir a por lo que está peor, a nosotros nos funciona mejor analizar qué mejor opción hubiera evitado ese bug, o esa tipología de bugs, que si que se nos dan frecuentemente.

Se pragmático. Suerte y que la agilidad te acompañe (si estás en una de estas lo vas a necesitar).

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

4 comentarios en “Reflexionando sobre el Testing, en modelos Ágiles… pero con la realidad del código legacy”

  1. Yo creo que de todo el post lo mejor es el uso e incorporación de la palabra happylandia o yo incluiría casi mejor los mundos de Yupi, y es que es la nave de Yupi que ya aterrizó…
    El tema de agilidad es lo que es, y puede servir en casos muy concretos para cosas muy concretas…, pero es eso, ir más lejos es vivir en los mundos de Yupi.
    Querer hacer en 5 minutos algo para lo que necesitas 5 meses es complicado, aunque a veces puedas simplificar, quedarte justo con lo justo y salir del apuro en 5 minutos y te sirva, pero es lo que es, un apaño que a lo mejor en un momento dado va bien e incluso era la mejor opción por ser lo más eficiente. Pero si vas de apaño en apaño, al final entre el legacy y los apaños, la cosa se va a ir poniendo complicadilla…

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *