Utilizzo del Rocket Software Unit Test Framework per facilitare test più intelligenti dei programmi del sottosistema mainframe

Autore aggiuntivo per questo post: Stephen Gennard

Introduzione

Dalla fine degli anni '80 con l'avvento di SUnit e negli anni '90 con l'introduzione di JUnit, l'uso dei test unitari supportati da un framework di test unitari è cresciuto rapidamente ed è diventato un approccio standard del settore per milioni di sviluppatori software all'interno della comunità di sviluppo di applicazioni distribuite.

La grande divisione

Per ragioni storiche di lunga data esiste una limitazione percepita associata al codice applicativo scritto per IBM^® Sottosistemi mainframe per quanto riguarda tali metodi di test. Scritto prevalentemente in COBOL e progettato per essere eseguito nei sottosistemi IBM.^® CICS^®, IMS e JES, il concetto di test unitario di questi programmi applicativi è stato tradizionalmente considerato un salto nel futuro troppo grande.

Noi di Rocket sosteniamo da tempo che queste applicazioni e i linguaggi di programmazione utilizzati per scriverle si integrino perfettamente nel moderno mondo dello sviluppo software. Rocket^® Enterprise Developer (formerly part of Micro Focus) e Rocket^® Visual COBOL (formerly part of Micro Focus) forniscono il Framework per i test unitari sin dal rilascio della versione 2.3 nel 2015.

Prima della versione 9.0 di Enterprise Developer, un programma COBOL contenente sia logica di business che istruzioni "EXEC SQL" e/o "EXEC CICS" non sarebbe stato un candidato ideale per un test unitario. Pertanto, la funzionalità MFUnit è stata ulteriormente evoluta per includere il supporto per le funzioni "ignore" e "mock" delle istruzioni EXEC CICS e SQL, rendendo più semplice che mai superare il "Great Divide" e introdurre metodologie di test più intelligenti nei programmi dei sottosistemi mainframe. Nell'ultima versione, la 10.0, è stato aggiunto un supporto iniziale per le istruzioni "EXEC DLI".

Non sorprende che, a causa di questa "grande divisione", al momento si sia scritto poco sull'importanza dell'utilizzo dei test unitari per il codice applicativo mainframe, ma ci sono molti articoli come questo che ne descrivono in dettaglio l'importanza. Se si percepisce un "pezzo specifico di software" come un paragrafo o una sezione COBOL, allora tutte le ragioni discusse si applicano ugualmente al codice mainframe.

Come può essere utilizzato?

Prima di addentrarci nei dettagli, è importante fornire alcune informazioni di contesto sull'utilizzo di queste nuove funzionalità EXEC SQL/CICS ignore e mocking.

Il suo scopo è quello di "rivelare" la logica COBOL in un programma basato su EXEC in modo che possa essere testato e non deve essere considerato come un metodo per testare applicazioni basate su CICS e/o SQL nel loro complesso.

Come funziona?

Il pre-processore Unit Test Seam (MFUPP) è stato migliorato per facilitare la creazione di test unitari autonomi che contengono istruzioni "EXEC CICS", "EXEC SQL" o "EXEC DLI".

Queste istruzioni EXEC possono essere rimosse o simulate a seconda dei requisiti del caso di test.

Anche Unit Test Runner è stato migliorato per agevolare lo sviluppo di questi stili di test unitari mediante l'aggiunta di nuove opzioni di generazione del codice disponibili tramite l'interfaccia della riga di comando.

Figura 1 - Pre-processore Seam per test unitari

Il pre-processore Unit Test Seam (MFUPP) consente di manipolare il codice senza modificare il codice sorgente originale, con il solo scopo di creare un test unitario.

Ha la capacità di inserire copybook in varie divisioni, rimuovere determinate istruzioni EXEC e inserire istruzioni di callback fittizie.

Produzione di test unitari

Considerando un programma che contiene istruzioni SQL incorporate, è ora possibile trasformarlo in un test unitario tramite uno o entrambi i seguenti meccanismi:

• Ignorare le istruzioni EXEC SQL
• Simulazione delle istruzioni SQL EXEC

Potrebbe sembrare strano avere una funzionalità di pre-processore Seam che rimuove il codice, ma è davvero utile quando si cerca di creare un test unitario di una sezione o di un paragrafo che include SQL incorporato

Se la sezione o il paragrafo COBOL da testare contiene una singola istruzione "EXEC SQL", allora è un candidato ideale per l'utilizzo della funzionalità di rimozione del pre-processore seam, poiché i valori aggiornati dall'istruzione "EXEC SQL" possono essere inclusi nel caso di test unitario senza bisogno di alcuna simulazione.

Figura 2 - Paragrafo COBOL con istruzione SQL incorporata

Imagine un programma COBOL che contiene un'istruzione EXEC SQL FETCH per ottenere una nuova riga di dati e poi esegue alcuni calcoli (logica aziendale) su di essa.

Senza l'uso del pre-processore Seam sarebbe necessario un database distribuito/utilizzabile disponibile per i test.

Successivamente, all'interno del caso di prova, sarebbe necessario che un cursore fosse aperto, pronto per il recupero, prima che il paragrafo possa essere testato.

Si tratta di un sovraccarico e di una configurazione notevoli per testare una sezione o un paragrafo. Figura 2 - Paragrafo COBOL con istruzione SQL incorporata

Figura 3 - Test unitario che ignora l'istruzione SQL

Utilizzando la funzionalità di test unitario autonomo del pre-processore Seam, è possibile creare un caso di test che verrà incorporato nel programma.

Ciò si ottiene scrivendo il caso di test nel nome file con prefisso MFUPD_ . Questo viene fatto per garantire l'accesso a tutti i campi del programma ed eseguire un paragrafo 50-FETCH-UPDATE .

Figura 4 - Test unitario che simula l'istruzione SQL.

L'esempio precedente di ScanEmployeeTable è ora evoluto

Ora è impossibile falsificare i valori di SQL FETCH semplicemente rimuovendo l'istruzione SQL EXEC, perché la prima cosa che fa il paragrafo "test" è inizializzare EMP-TABLE, eliminando così qualsiasi impostazione di variabile.

Quindi ora è necessario prendere in giro.

Come per il supporto al program mocking, fornito prima di questa versione, è necessario registrare un entry-point che funga da controller. Questa operazione viene effettuata nel metadati entry-point e il nome del simbolo viene inserito nel campo MFU-MD-EXEC-CONTROLLER .

Successivamente, dobbiamo dichiarare un punto di ingresso per gestire l'istruzione SQL fittizia; in questo esempio, è qui che verranno impostate le istruzioni di spostamento necessarie per simulare questa istruzione FETCH .

In questo semplice esempio non vengono dichiarati tutti i parametri, poiché non li stiamo utilizzando.

Il supporto del pre-processore Unit Test Seam per le istruzioni "EXEC CICS" è progettato per risultare familiare, poiché le sue funzionalità sono simmetriche a quelle fornite per le istruzioni "EXEC SQL".

Ignorare le istruzioni "EXEC CICS" e "EXEC DLI" è semplice come per le istruzioni "EXEC SQL" e la simulazione utilizza lo stesso meccanismo di callback.

Figura 5 - Esempi di istruzioni EXEC DLI ignorate.

Aiutare a scrivere test unitari

Ogni modernizzazione richiede investimenti per ottenere il massimo valore, ma qualsiasi strumento di test dovrebbe supportare lo sviluppatore nella produzione di casi di test il più possibile. A tal fine, il framework MFUnit include una funzionalità di generazione di frammenti di codice per creare codice che aiuti a simulare l'istruzione EXEC con il programma in fase di test.

Figura 5 - Esempi di ID univoci per istruzioni simulate.

Per impostazione predefinita, il generatore di frammenti crea un frammento fittizio per ogni istruzione EXEC.

A ogni istruzione simulata viene assegnato un ID univoco; questo identificatore può essere modificato aggiungendo un commento al codice prima dell'istruzione EXEC .

Ciò consente al generatore di frammenti di creare un codice dall'aspetto più pulito, limitando la generazione del codice solo a questi identificatori personalizzati.

Figura 6 - Aiuto quando il programma simulato utilizza COMMAREA

Un programma CICS può utilizzare una COMMAREA, che è qualcosa che il normale CICS ECM gestirebbe. Tuttavia, un caso di test potrebbe richiedere che questa sia inizializzata e disponibile per il popolamento da parte di un caso di test. Il pre-processore Seam inserisce due paragrafi aggiuntivi che possono essere utilizzati.

La sezione MFUPP--INIT-CICS alloca la COMMAREA e inserisce la dimensione in EIBCALEN.

Quando non è più necessario utilizzare COMMAREA, è possibile utilizzare la sezione MFUPP--END-CICS.

Riepilogo

Unit Test Framework, disponibile con Enterprise Developer, presenta due nuove funzionalità nel pre-processore Seam.

La prima consiste nel rimuovere o ignorare `EXEC SQL`, `EXEC CICS` e `EXEC DLI` che rivelano la logica da testare senza bisogno di alcuna simulazione.

Il secondo, il supporto per la simulazione delle istruzioni EXEC, consente alternative semplificate alle istruzioni EXEC che forniscono al programma dati sufficienti per consentirne il test.

Grazie a questo supporto aggiuntivo, i programmi dei sottosistemi mainframe possono essere testati rapidamente, poiché non è necessario il sottosistema stesso, né la fornitura di dati. Infatti, l'unica cosa di cui si ha bisogno per testare il codice è il codice stesso.

Per vedere qualcosa di tutto questo in azione, guarda questo video .