Automatización de tests para un emulador IBM legacy
Junio 2019 – July 2020
También disponible en EN →
TL;DR
- Uno de ocho desarrolladores en el equipo del emulador, en una empresa de unas veinte personas
- Validación manual reemplazada por una suite de tests completamente automatizada y desatendida
- Único usuario de Linux del equipo: descubrió bugs dependientes del SO presentes desde años
- Introdujo git y Maven para modernizar prácticas que nadie había cuestionado antes
El contexto
BASE100 desarrolla Caravel, un emulador y conversor de software legacy para IBM i Series (AS/400). La herramienta convierte y ejecuta código de negocio de décadas en infraestructura moderna. El tipo de trabajo que exige garantías de corrección muy altas.
El equipo que desarrollaba el emulador era de unas ocho personas, en una empresa de unas veinte.
El proceso de testing cuando llegué era completamente manual: cargar datos, ejecutar conversiones, inspeccionar outputs, comparar contra los resultados esperados. Lento, inconsistente, y tan fiable como la persona que lo ejecutaba ese día.
Lo que construí
Automaticé el flujo completo. Un único script podía ahora obtener código y datos remotos, poblar las bases de datos de test, ejecutar las conversiones y emulaciones, validar los outputs contra los resultados esperados y generar un informe. Lo que antes eran horas de trabajo manual se convirtió en un proceso repetible y desatendido.
Los scripts estaban escritos en Python y shell, dirigidos por definiciones de test en texto plano, lo que además significaba que cualquiera podía añadir un nuevo caso de test sin tocar las herramientas.
También contribuí al core de Caravel: nuevas funcionalidades del emulador y refactorización de código Java de más de una década para reducir la deuda técnica. Y aproveché para introducir git y Maven en un equipo que aún trabajaba con CVS y Ant. No porque me lo pidieran, sino porque la alternativa era demasiado dolorosa.
El factor Linux
Era la única persona del equipo usando Linux. Esto resultó ser una casualidad útil.
El código tenía cadenas de ruta hardcodeadas por todas partes: el tipo de cosa que funciona bien en Windows y falla estruendosamente en cualquier otro sitio. Las reemplacé por los constructores adecuados de Java (File.separator, Paths.get()) y documenté el resto. Era un cambio pequeño técnicamente, pero revelaba una suposición integrada en el código: que siempre correría en Windows, para siempre.
También encontré un Boolean (con B mayúscula, la versión boxed) siendo usado como variable de tres estados: true, false o null, cada uno con un significado distinto. Propuse reemplazarlo por un enum adecuado. El tech lead no estuvo de acuerdo. Lo anoté, seguí adelante, y lo archivé bajo “lecciones sobre elegir las batallas en bases de código legacy.”