Uso del marco de pruebas unitarias de Rocket Software para facilitar pruebas más inteligentes de programas del subsistema de mainframe

Autor adicional de esta publicación: Stephen Gennard

Introducción

Desde fines de la década de 1980 y la llegada de SUnit y más allá de la década de 1990 y la introducción de JUnit, el uso de pruebas unitarias respaldadas por un marco de pruebas unitarias ha crecido rápidamente y se ha convertido en un enfoque estándar de la industria para millones de desarrolladores de software dentro de la comunidad de desarrollo de aplicaciones distribuidas.

La gran división

Por razones históricas de larga data, existe una limitación percibida asociada con el código de aplicación escrito para IBM^® Subsistemas de mainframe con respecto a dichos métodos de prueba. Escritos principalmente en COBOL y diseñados para ejecutarse en los subsistemas de IBM.^® CICS^®, IMS y JES, el concepto de realizar pruebas unitarias en estos programas de aplicación se ha considerado tradicionalmente un salto demasiado grande.

En Rocket, desde hace tiempo defendemos que estas aplicaciones y los lenguajes de programación utilizados para escribirlas se integran perfectamente en el mundo moderno del desarrollo de software. Rocket^® Enterprise Developer (formerly part of Micro Focus) y Rocket^® Visual COBOL (formerly part of Micro Focus) proporcionan el marco de pruebas unitarias desde el lanzamiento de la versión 2.3 en 2015.

Antes de la versión 9.0 de Enterprise Developer, un programa COBOL que contuviera lógica de negocio y sentencias "EXEC SQL" o "EXEC CICS" no habría sido ideal para una prueba unitaria. Por ello, la funcionalidad de MFUnit se ha desarrollado aún más para incluir compatibilidad con la función de ignorar y simular sentencias EXEC CICS y SQL, lo que facilita más que nunca superar la "Gran División" e implementar metodologías de prueba más inteligentes para los programas de subsistemas de mainframe. En la última versión, la 10.0, se ha añadido compatibilidad inicial con sentencias "EXEC DLI".

Como era de esperar, debido a esta "Gran División", actualmente se ha escrito poco sobre la utilidad de usar pruebas unitarias en el código de aplicaciones mainframe, pero existen muchos artículos como este que detallan su valor. Si considera un "software específico" como un párrafo o sección COBOL, entonces todas las razones expuestas se aplican por igual al código mainframe.

¿Cómo se puede utilizar?

Antes de profundizar más en los detalles, es importante establecer algo de contexto en torno al uso de estas nuevas funciones de ignorancia y burla de EXEC SQL/CICS.

Su propósito es "revelar" la lógica COBOL en un programa basado en EXEC para que pueda probarse y no debe considerarse como un método para probar aplicaciones basadas en CICS y/o SQL en su totalidad.

¿Cómo funciona?

El preprocesador Unit Test Seam (MFUPP) se ha mejorado para facilitar la creación de pruebas unitarias autónomas que contienen instrucciones "EXEC CICS", "EXEC SQL" o "EXEC DLI".

Estas declaraciones EXEC se pueden eliminar o simular según el requisito del caso de prueba.

El Unit Test Runner también se ha mejorado para ayudar al desarrollo de estos estilos de pruebas unitarias mediante la adición de nuevas opciones de generación de código disponibles a través de la interfaz de línea de comandos.

Figura 1 - Preprocesador de costura de prueba unitaria

El preprocesador Unit Test Seam (MFUPP) permite manipular el código sin cambiar el código fuente original con el único propósito de crear una prueba unitaria.

Tiene la capacidad de insertar libros de copias en varias divisiones, eliminar ciertas declaraciones EXEC e insertar declaraciones de devolución de llamadas simuladas.

Producción de pruebas unitarias

Considerando un programa que contiene sentencias SQL integradas, ahora puede convertirse en una prueba unitaria mediante uno o ambos de los siguientes mecanismos:

• Ignorar las declaraciones SQL EXEC
• Burlarse de las declaraciones SQL EXEC

Puede parecer extraño tener una función de preprocesador de costura que elimine código, pero es realmente útil cuando se intenta crear una prueba unitaria de una sección o párrafo que incluye SQL integrado.

Si la sección o el párrafo COBOL que se va a probar tiene una sola declaración "EXEC SQL", entonces es un candidato ideal para usar la función de eliminación del preprocesador de costura, ya que los valores actualizados por la declaración "EXEC SQL" se pueden incluir en el caso de prueba unitaria sin la necesidad de ninguna simulación.

Figura 2 - Párrafo COBOL con declaración SQL incorporada

Imagine un programa COBOL que contiene una declaración EXEC SQL FETCH para obtener una nueva fila de datos y luego realiza algunos cálculos (lógica empresarial) en ella.

Sin el uso del preprocesador de costura, sería necesario disponer de una base de datos implementada y utilizable para realizar pruebas.

A continuación, dentro del caso de prueba, se debería haber abierto un cursor listo para la búsqueda antes de poder probar el párrafo.

Esto supone una gran sobrecarga y configuración para probar una sección o un párrafo. Figura 2: Párrafo COBOL con sentencia SQL integrada.

Figura 3 - Prueba unitaria que ignora la declaración SQL

Utilizando la función de prueba unitaria autónoma del preprocesador Seam, se puede crear un caso de prueba que se integrará en el programa.

Esto se logra escribiendo el caso de prueba en el nombre de archivo con el prefijo MFUPD_ . Esto garantiza el acceso a todos los campos del programa y la ejecución de un párrafo 50-FETCH-UPDATE .

Figura 4 - Prueba unitaria simulando la declaración SQL.

El ejemplo anterior de ScanEmployeeTable ahora ha evolucionado

Ahora es imposible falsificar los valores de SQL FETCH simplemente eliminando la declaración SQL EXEC porque lo primero que hace el párrafo "prueba" es inicializar EMP-TABLE, descartando así la configuración de cualquier variable.

Así que ahora es necesario burlarse.

Al igual que con la compatibilidad con la simulación de programas, disponible antes de esta versión, es necesario registrar un punto de entrada para que actúe como controlador. Esto se realiza en el punto de entrada de metadatos y el nombre del símbolo se coloca en el campo MFU-MD-EXEC-CONTROLLER .

A continuación, debemos declarar un punto de entrada para manejar la declaración SQL simulada, para este ejemplo, aquí es donde se configurarán las declaraciones de movimiento necesarias para simular esta declaración FETCH .

Para este ejemplo simple no se declaran todos los parámetros, ya que no los utilizamos.

El soporte del preprocesador Unit Test Seam para declaraciones “EXEC CICS” está diseñado para resultar familiar, ya que sus características son simétricas a las proporcionadas para las declaraciones “EXEC SQL”.

Ignorar las declaraciones “EXEC CICS” y “EXEC DLI” es tan simple como lo es para las declaraciones “EXEC SQL” y la burla utiliza el mismo mecanismo de devolución de llamada.

Figura 5 - Ejemplos de ignorancia de declaraciones EXEC DLI.

Ayudando a escribir pruebas unitarias

Toda modernización requiere inversión para obtener el máximo provecho, pero cualquier herramienta de prueba debe ayudar al desarrollador a generar casos de prueba en la medida de lo posible. Para ello, el framework MFUnit incluye una función de generación de fragmentos de código que permite simular la sentencia EXEC con el programa bajo prueba.

Figura 5 – Ejemplos de ID únicos para declaraciones simuladas.

De forma predeterminada, el generador de fragmentos crea un fragmento simulado para cada declaración EXEC.

A cada declaración simulada se le asigna un ID único, este identificador se puede cambiar instrumentando el código antes de la declaración EXEC con un comentario.

Esto permite que el generador de fragmentos cree un código más limpio al restringir la generación de código solo a estos identificadores personalizados.

Figura 6 - Ayuda cuando el programa simulado usa COMMAREA

Un programa CICS puede usar un COMMAREA, algo que el ECM de CICS normal gestionaría. Sin embargo, un caso de prueba puede requerir que este se inicialice y esté disponible para su rellenado. El preprocesador Seam inyecta dos párrafos adicionales que pueden usarse.

La sección MFUPP--INIT-CICS asigna el COMMAREA y coloca el tamaño en EIBCALEN.

Cuando ya no sea necesario el uso de COMMAREA, se podrá utilizar la sección MFUPP--END-CICS.

Resumen

El Unit Test Framework, disponible con Enterprise Developer, tiene dos nuevas características en el preprocesador Seam.

El primero, la eliminación o ignorancia de `EXEC SQL`, `EXEC CICS` y "EXEC DLI" que revelan la lógica a probar sin necesidad de ninguna burla.

El segundo, el soporte de simulación de sentencias EXEC, permite alternativas simplificadas a las sentencias EXEC que brindan al programa los datos suficientes para permitir su prueba.

Con este soporte adicional, los programas del subsistema mainframe pueden probarse rápidamente, ya que no se requiere el subsistema en sí ni el suministro de datos. De hecho, lo único que se necesita para probar el código es el código mismo.

Para ver algo de esto en acción, mire este video .