Utilizando a estrutura de testes unitários da Rocket Software para facilitar testes mais inteligentes de programas do subsistema Mainframe.

Autor adicional desta publicação: Stephen Gennard

Introdução

Desde o final da década de 1980, com o surgimento do SUnit, e posteriormente ao longo da década de 1990, com a introdução do JUnit, o uso de testes unitários suportados por uma estrutura de testes unitários cresceu rapidamente e se tornou uma abordagem padrão da indústria para milhões de desenvolvedores de software na comunidade de desenvolvimento de aplicações distribuídas.

A grande divisão

Por razões históricas de longa data, existe uma limitação percebida associada ao código de aplicação escrito para os subsistemas IBM^® Mainframe no que diz respeito a esses métodos de teste. Predominantemente escrito em COBOL e projetado para rodar nos subsistemas IBM^® CICS^®, IMS e JES, o conceito de teste unitário desses programas de aplicação tem sido tradicionalmente considerado um salto muito grande para o futuro.

Na Rocket, sempre defendemos que esses aplicativos e as linguagens de programação usadas para escrevê-los se encaixam perfeitamente no mundo moderno do desenvolvimento de software. O Rocket^® Enterprise Developer (formerly part of Micro Focus) e o Rocket^® Visual COBOL (formerly part of Micro Focus) fornecem a estrutura de testes unitários desde o lançamento da versão 2.3 em 2015.

Antes do lançamento da versão 9.0 do Enterprise Developer, um programa COBOL que contivesse lógica de negócios e instruções "EXEC SQL" e/ou "EXEC CICS" não seria um candidato ideal para um teste unitário. Portanto, a funcionalidade MFUnit foi aprimorada para incluir suporte para 'ignorar' e simular instruções EXEC CICS e SQL, tornando mais simples do que nunca transpor a "Grande Divisão" e trazer metodologias de teste mais inteligentes para programas de subsistemas de mainframe. Na versão mais recente, 10.0, foi adicionado suporte inicial para instruções "EXEC DLI".

Não é de surpreender que, devido a essa "Grande Divisão", haja atualmente pouca informação escrita sobre o valor do uso de testes unitários para código de aplicações mainframe, mas existem muitos artigos como este, que detalham o valor dos testes unitários. Se você considera um "software específico" como um parágrafo ou seção COBOL, então todos os motivos discutidos se aplicam igualmente ao código mainframe.

Como pode ser usado?

Antes de entrarmos em detalhes, é importante contextualizar o uso desses novos recursos de ignorar e simular comandos EXEC SQL/CICS.

Seu objetivo é "revelar" a lógica COBOL em um programa baseado em EXEC para que possa ser testado e não deve ser considerado um método para testar aplicativos baseados em CICS e/ou SQL como um todo.

Como funciona?

O pré-processador Unit Test Seam (MFUPP) foi aprimorado para auxiliar na criação de testes unitários autocontidos que contenham instruções "EXEC CICS", "EXEC SQL" ou "EXEC DLI".

Essas instruções EXEC podem ser removidas ou simuladas, dependendo da necessidade do caso de teste.

O Unit Test Runner também foi aprimorado para auxiliar no desenvolvimento desses estilos de testes unitários, com a adição de novas opções de geração de código disponíveis por meio da interface de linha de comando.

Figura 1 - Pré-processador de costura para teste unitário

O pré-processador Unit Test Seam (MFUPP) permite que o código seja manipulado sem alterar o código-fonte original, com o único objetivo de criar um teste unitário.

Possui a capacidade de inserir copybooks em várias divisões, remover determinadas instruções EXEC e inserir instruções de retorno de chamada simuladas.

Produzindo testes unitários

Considerando um programa que contém instruções SQL incorporadas, ele agora pode ser transformado em um teste unitário por um ou ambos os seguintes mecanismos:

• Ignorando a(s) instrução(ões) EXEC SQL
• Simulação da(s) instrução(ões) EXEC SQL

Pode parecer estranho ter um recurso de pré-processador de costura que remove código, mas é realmente útil ao tentar criar um teste unitário de uma seção ou parágrafo que inclua SQL incorporado.

Se a seção ou parágrafo COBOL a ser testado contiver uma única instrução "EXEC SQL", então é um candidato ideal para usar o recurso de remoção do pré-processador de costura, pois os valores atualizados pela instrução "EXEC SQL" podem ser incluídos no caso de teste unitário sem a necessidade de qualquer simulação.

Figura 2 - Parágrafo COBOL com instrução SQL incorporada

Imagine um programa COBOL que contém uma instrução EXEC SQL FETCH para obter uma nova linha de dados e, em seguida, realiza alguns cálculos (lógica de negócios) sobre ela.

Sem a utilização do pré-processador de costura, seria necessário ter um banco de dados implantado/utilizável disponível para testes.

Em seguida, dentro do caso de teste, um cursor precisaria estar aberto e pronto para a busca antes que o parágrafo pudesse ser testado.

Isso representa uma grande sobrecarga e necessidade de configuração para testar uma seção ou parágrafo. Figura 2 - Parágrafo COBOL com instrução SQL incorporada

Figura 3 - Teste unitário ignorando a instrução SQL

Utilizando o recurso de teste de unidade independente do pré-processador Seam, é possível criar um caso de teste que será incorporado ao programa.

Isso é conseguido escrevendo o caso de teste no nome do arquivo com o prefixo MFUPD_ . Isso é feito para garantir que possamos acessar todos os campos do programa e executar um parágrafo FETCH-UPDATE .

Figura 4 - Teste unitário simulando a instrução SQL.

O exemplo anterior de ScanEmployeeTable evoluiu.

Agora é impossível falsificar os valores do SQL FETCH simplesmente removendo a instrução SQL EXEC, porque a primeira coisa que o parágrafo "teste" faz é inicializar a tabela EMP, descartando assim qualquer configuração de variável.

Agora, portanto, é necessário zombar.

Assim como no suporte à simulação de programas, fornecido antes desta versão, é necessário registrar um ponto de entrada para atuar como controlador. Isso é feito no ponto de entrada de metadados, e o nome do símbolo é inserido no campo MFU-MD-EXEC-CONTROLLER .

Em seguida, precisamos declarar um ponto de entrada para lidar com a instrução SQL simulada; neste exemplo, é aqui que as instruções MOVE necessárias para simular esta instrução FETCH serão configuradas.

Neste exemplo simples, nem todos os parâmetros foram declarados, pois não os estamos utilizando.

O suporte do pré-processador Unit Test Seam para instruções “EXEC CICS” foi projetado para proporcionar uma sensação familiar, já que seus recursos são simétricos aos fornecidos para instruções “EXEC SQL”.

Ignorar as instruções “EXEC CICS” e “EXEC DLI” é tão simples quanto ignorar as instruções “EXEC SQL”, e a simulação utiliza o mesmo mecanismo de retorno de chamada.

Figura 5 - Exemplos de como ignorar instruções EXEC DLI.

Auxiliar na escrita de testes unitários.

Toda modernização requer investimento para que seu valor total seja alcançado, mas qualquer ferramenta de teste deve auxiliar o desenvolvedor na criação de casos de teste o máximo possível. Para esse fim, o framework MFUnit inclui um recurso de geração de trechos de código para criar código que ajude a simular a instrução EXEC no programa em teste.

Figura 5 - Exemplos de IDs únicos para instruções simuladas.

Por padrão, o gerador de trechos de código cria um trecho de código fictício para cada instrução EXEC.

Cada instrução simulada recebe um ID único; esse identificador pode ser alterado instrumentando o código antes da instrução EXEC com um comentário.

Isso permite que o gerador de trechos de código crie um código com aparência mais limpa, restringindo a geração de código apenas a esses identificadores personalizados.

Figura 6 - Ajuda quando o programa simulado usa COMMAREA

Um programa CICS pode usar uma COMMAREA, algo que o ECM do CICS normalmente gerenciaria. No entanto, um caso de teste pode exigir que essa COMMAREA seja inicializada e esteja disponível para ser preenchida pelo próprio caso de teste. O pré-processador Seam injeta dois parágrafos extras que podem ser utilizados.

A seção MFUPP--INIT-CICS aloca a COMMAREA e define seu tamanho em EIBCALEN.

Quando o uso da COMMAREA não for mais necessário, a seção MFUPP--END-CICS poderá ser utilizada.

Resumo

O Unit Test Framework, disponível no Enterprise Developer, possui dois novos recursos no pré-processador Seam.

A primeira medida consiste em remover ou ignorar os comandos `EXEC SQL`, `EXEC CICS` e `EXEC DLI`, que revelam a lógica a ser testada sem a necessidade de simulações.

A segunda funcionalidade, o suporte para simulação de instruções EXEC, permite alternativas simplificadas às instruções EXEC, fornecendo ao programa apenas os dados necessários para que ele possa ser testado.

Com esse suporte adicional, os programas do subsistema mainframe podem ser testados rapidamente, pois o próprio subsistema não é necessário, nem o fornecimento de quaisquer dados. Na verdade, a única coisa necessária para testar o código é o próprio código.

Para ver um pouco disso em ação, assista a este vídeo .