Automatizar pruebas Cobol o RPG

Hace mucho tiempo me había surgido la necesidad de investigar cómo automatizar pruebas End-to-End para sistemas de pantalla verde. Se trataba de un sistema que funcionaba en un AS400 (o iSeries), y no recuerdo bien si estaba desarrollado en RPG o Cobol (aunque al fin de cuentas, creo que no plantea ninguna diferencia al análisis). Luego de investigar, preguntar en foros y darle vueltas, lo más cerca que estuve fue con una librería llamada TN5250J, para Java, que la pude hacer funcionar para automatizar algo básico. La desventaja quizá es que queda poco práctico automatizar pruebas complejas. Dejo por acá mis notas, así como el código de la prueba de concepto que hice para ver cómo automatizar pruebas Cobol o RPG.

Automatizar TN5250

El protocolo de terminal 5250 envía un stream (básicamente de texto) sobre el protocolo Telnet. Para poder manejarlo se puede usar, por ejemplo, la implementación TN5250J (Java y open source). Esta librería ofrece un emulador del cliente, y brinda una API para interactuar con él mediante scripting tal como se explica acá. Estas pruebas se podrían programar usando Jython.

También se puede usar directamente la librería en Java sin hacer cosas en Python. Esta fue la opción que yo llegué a probar, también con el fin de hacer la simulación a nivel de protocolo y sin la necesidad de abrir la interfaz gráfica del cliente. Al hacerlo así, tal vez se podría considerar a futuro esta automatización para hacer pruebas de performance con concurrencia.

El TN5250J también soporta el uso de macros en la propia interfaz, con un enfoque Record and Playback, pero tampoco lo probé.

Prueba de concepto

Armé una prueba de concepto que la podés bajar y usar desde el proyecto en mi cuenta de Github. Me basé en lo que encontré en este post, donde se explica más el funcionamiento de la librería, y le hice algunos ajustes que fui necesitando.

Ambiente de pruebas

Esto es todo un tema. ¿De dónde saco un ambiente de pruebas AS400 para hacer una prueba de concepto? Luego de mucho buscar, lo que encontré fue un servicio que se puede acceder a la pantalla de login, y al menos probar intentar acceder (usando un usuario y password incorrectos, verificando que no me deja acceder ?).

Así entonces, mi ambiente de pruebas es rikas.rikascom.net.

Mecanismo de automatización

La parte poco práctica de esto es la identificación de los campos. Se identifican por número, pero es difícil saber qué campo es el que queremos actuar. Para esto hice un método “exploreScreenFields” que obtiene la lista de fields e imprime en pantalla la lista de identificadores, con el texto que tienen a la izquierda. Fue la forma que encontré de poder saber cuál es cuál.

También hice un método para imprimir el texto de la pantalla considerando el ancho de caracteres de la misma, así la podía dibujar e ir viendo qué me respondía el servidor en cada invocación.

Conclusión

Esta solución si bien creo que es muy artesanal, seguro que sirve para algunas automatizaciones que se necesiten hacer.

Posts relacionados:

¿En qué nivel conviene automatizar? Automatizar durante el sprint o en cascada CvsParser para data-driven en pruebas automatizadas Recuperando la confianza en las pruebas automatizadas