 |
| Bellacosa Mainframe e os testes automatizados |
☕ Um Café no Bellacosa Mainframe
Dr. Strangelove e a Arte de Parar de se Preocupar e Amar os Testes
🧪 Um guia para o programador COBOL iniciante entender Unit Test, Component Test, Integration, E2E, APIs, Db2, CICS, IA, Mutation Testing, Chaos Engineering e por que um MAXCC=0 não significa que o mundo está salvo
Imagine a cena.
Uma sala subterrânea.
Luzes fracas.
Painéis verdes piscando.
Um enorme mapa operacional ocupa a parede.
Generais discutem nervosamente ao redor de uma mesa enquanto alguém observa um terminal 3270.
De repente, surge a mensagem:
IEF142I PAYROLL STEP030 - STEP WAS EXECUTED - COND CODE 0000
Silêncio.
Um jovem programador COBOL ergue os braços:
— Funcionou!
Do outro lado da mesa, um velho sysprog ajusta os óculos.
— O job terminou com RC=0.
— Exatamente! Funcionou!
— Eu disse que terminou.
— E qual é a diferença?
Nesse momento, uma música imaginária começa a tocar e, em algum lugar entre o JES2, o Db2 e um endpoint REST perdido na nuvem, o Dr. Strangelove levanta lentamente a mão mecânica.
Bem-vindo ao maravilhoso mundo dos testes de software.
Porque existe uma diferença monumental entre:
O PROGRAMA EXECUTOU
e:
O PROGRAMA FEZ A COISA CERTA.
E existe uma diferença ainda maior entre:
O PROGRAMA FEZ A COISA CERTA UMA VEZ.
e:
O SISTEMA CONTINUARÁ FAZENDO A COISA CERTA
QUANDO O BANCO ESTIVER LENTO,
O MQ ESTIVER INDISPONÍVEL,
O USUÁRIO CLICAR DUAS VEZES,
O RACF NEGAR ACESSO
E UM ARQUIVO CHEGAR COM 17 BYTES A MENOS.
Essa diferença se chama engenharia.
🦖 Antes de qualquer coisa: o teste não existe para provar que você é inteligente
Essa talvez seja a primeira lição para quem está começando em COBOL.
Testar não é demonstrar que o programa está bonito.
Não é mostrar ao chefe:
100% DE COVERAGE
e sair correndo em direção ao café.
Testar é produzir evidência de que o comportamento esperado existe.
Pense em um programa COBOL simples:
IF WS-IDADE >= 18
MOVE 'MAIOR' TO WS-STATUS
ELSE
MOVE 'MENOR' TO WS-STATUS
END-IF.
Parece fácil.
Então alguém testa:
IDADE = 25
RESULTADO = MAIOR
Passou.
Parabéns.
Temos uma evidência.
Mas ainda sabemos pouco.
Teste também:
IDADE = 17
IDADE = 18
IDADE = 19
IDADE = 0
IDADE = 999
IDADE = -1
Nesse ponto começamos a perceber algo fundamental.
O trabalho interessante não é apenas perguntar:
funciona?
A pergunta interessante é:
em quais condições funciona, em quais condições falha e o que significa falhar corretamente?
🔬 UNIT TEST — o microscópio do programador
Unit Test é o teste da menor unidade lógica razoável.
Em COBOL isso pode ser:
um parágrafo;
uma SECTION;
uma rotina;
uma regra de negócio isolada;
uma transformação;
um cálculo.
Imagine:
CALCULA-JUROS.
COMPUTE WS-JUROS =
WS-VALOR * WS-TAXA / 100.
Podemos testar:
VALOR = 1000
TAXA = 10
JUROS = 100
Mas um bom programador vai além:
VALOR = 0
TAXA = 10
VALOR = 1000
TAXA = 0
VALOR = 1000
TAXA = -10
VALOR = 999999999
TAXA = 99.99
Aqui aparece uma das primeiras curiosidades importantes para quem entra no mundo COBOL:
💰 Dinheiro é uma criatura traiçoeira
COBOL é historicamente excelente para sistemas financeiros justamente porque possui representação decimal adequada.
Mesmo assim, você precisa pensar em:
PIC 9(9)V99
PIC S9(9)V99 COMP-3
ROUNDED
ON SIZE ERROR
Um cálculo pode estar matematicamente correto e ainda produzir problema de tamanho, arredondamento ou sinal.
O Unit Test serve justamente para transformar essas hipóteses em fatos verificáveis.
🧩 COMPONENT TEST — quando várias engrenagens começam a conversar
Um componente é maior que uma função isolada.
Imagine um programa:
PROGRAMA DE CADASTRO
VALIDA CPF
↓
VALIDA DATA
↓
CALCULA SCORE
↓
CLASSIFICA CLIENTE
↓
MONTA REGISTRO
Você pode testar cada rotina separadamente.
Depois pode testar o componente completo sem necessariamente acessar Db2, CICS ou MQ.
Por exemplo:
ENTRADA
CPF válido
idade 43
renda 8000
SAÍDA
cliente aceito
score 742
categoria B
Isso começa a testar o comportamento da aplicação como conjunto.
É um pouco como testar o motor inteiro depois de testar pistão, válvula e injeção separadamente.
🟩 INTEGRATION TEST — “Vocês dois realmente conseguem conversar?”
Aqui começam algumas das melhores explosões cinematográficas.
Imagine:
PROGRAMA COBOL
↓
Db2
Seu programa pode estar perfeito.
Sua tabela também.
Mas a integração pode falhar porque:
coluna mudou
tipo mudou
package não está bindado
plan errado
authorization falhou
SQLCODE inesperado
connection indisponível
Ou:
COBOL
↓
MQ
↓
JAVA
O programa COBOL envia:
CUSTOMER-ID=00001234
O Java espera:
customerId=1234
Os dois programas podem passar individualmente em todos os testes.
Juntos:
💥
Esse é o território do Integration Testing.
🐳 Testcontainers e a revolução do “vamos testar com algo parecido com produção”
No mundo distribuído moderno existe uma ferramenta muito interessante chamada Testcontainers.
Ela permite criar dependências reais durante o teste.
Por exemplo:
TESTE
↓
sobe PostgreSQL
↓
executa aplicação
↓
testa
↓
derruba PostgreSQL
Isso evita uma velha armadilha:
Produção = banco A
Teste = banco B parecido
A palavra perigosa aqui é:
parecido.
Em computação, “parecido” é frequentemente irmão de “incidente”.
No mainframe temos uma filosofia semelhante quando criamos ambientes de teste com Db2, VSAM, MQ, CICS e configurações próximas de produção.
Quanto maior a fidelidade do ambiente, maior tende a ser nossa confiança.
Mas também maior o custo.
E aqui começa a aparecer a famosa pirâmide.
🔺 A PIRÂMIDE DOS TESTES
Imagine:
/\
/ \
/ E2E\
/------\
/INTEGR. \
/----------\
/ COMPONENT \
/--------------\
/ UNIT \
/___________________\
A ideia é simples.
Na base:
MUITOS TESTES
RÁPIDOS
BARATOS
ISOLADOS
No topo:
POUCOS TESTES
LENTOS
CAROS
COM MUITAS DEPENDÊNCIAS
Não existe uma porcentagem mágica.
Você encontrará gente repetindo:
70% Unit
20% Integration
10% E2E
Não trate isso como mandamento gravado em pedra por Moisés depois de um IPL.
É apenas uma heurística.
A arquitetura do sistema deve determinar a estratégia.
🎭 END-TO-END — agora queremos saber se o usuário consegue sobreviver
End-to-End Test, ou E2E, acompanha uma jornada completa.
Imagine Internet Banking:
cliente abre navegador
↓
login
↓
consulta conta
↓
faz transferência
↓
confirma
↓
recebe comprovante
Nos bastidores:
Browser
↓
Frontend
↓
API Gateway
↓
OAuth
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2
↓
MQ
↓
outro sistema
Agora temos algo muito próximo da realidade.
Excelente.
Só existe um pequeno problema:
se o teste falhar, quem matou o coronel?
Pode ser:
browser
CSS selector
rede
token
API
DNS
z/OS Connect
CICS
COBOL
Db2
MQ
serviço remoto
ambiente de teste
Um único:
FAILED
pode significar vinte coisas diferentes.
É por isso que E2E é extremamente valioso, mas também caro.
👻 O monstro chamado Flaky Test
Agora chegamos a uma criatura verdadeiramente perigosa.
O flaky test.
Hoje:
PASS
Amanhã:
FAIL
Executa novamente:
PASS
O programador aprende:
quando falhar, roda novamente
Essa é uma péssima situação.
Depois de alguns meses:
PIPELINE FAILED
e alguém responde:
— Deve ser aquele teste.
Roda novamente.
Passa.
A partir desse momento, o sistema de testes começou a perder autoridade.
Isso é equivalente a um alarme de incêndio que dispara todos os dias sem incêndio.
No começo todo mundo corre.
Depois de três meses:
— Ah, é aquele alarme.
Até o dia em que o prédio realmente pega fogo.
📊 COVERAGE — a estatística favorita para impressionar PowerPoint
Imagine:
IF WS-SALDO >= WS-VALOR
PERFORM EFETUA-SAQUE
END-IF.
Você cria um teste:
SALDO = 1000
VALOR = 100
A linha foi executada.
Coverage:
100%
Maravilhoso.
Mas você testou:
SALDO = 100
VALOR = 100
?
E:
SALDO = 99
VALOR = 100
?
Coverage mede frequentemente:
o código foi executado?
Não necessariamente:
o comportamento foi corretamente verificado?
É uma diferença monumental.
🧬 MUTATION TESTING — quem testa os testes?
Essa técnica é maravilhosa.
Imagine seu código:
IF WS-IDADE >= 18
Uma ferramenta de mutation testing altera deliberadamente para:
IF WS-IDADE > 18
Depois executa seus testes.
Se eles continuarem passando:
🤨
talvez ninguém esteja realmente testando a fronteira:
IDADE = 18
Mutation Testing basicamente pergunta:
se eu introduzir um pequeno defeito proposital, seus testes percebem?
É uma pergunta muito mais poderosa do que apenas coverage.
🔐 SECURITY TESTING — “funcionar” não significa “ser seguro”
Imagine:
Administrador consegue consultar salários?
Teste:
PASS
Ótimo.
Agora faça a pergunta de segurança:
Usuário comum consegue consultar salários?
Se a resposta for sim:
Parabéns.
Sua aplicação funciona perfeitamente
e está perfeitamente vulnerável.
Security Testing precisa verificar:
autenticação
autorização
privilégio
validação de entrada
segregação
sessão
tokens
exposição de dados
No mainframe:
RACF
SAF
ACEE
profiles
FACILITY
SURROGAT
dataset access
CICS transactions
Um programa COBOL pode produzir exatamente o resultado esperado e ainda ser um desastre de segurança.
⚡ PERFORMANCE TESTING — funciona com um usuário. E com cinquenta mil?
Imagine:
transação demora 50 ms
Excelente.
Então chegam:
10 usuários
100 usuários
1.000 usuários
20.000 usuários
Aí começamos a medir:
CPU
elapsed time
throughput
locks
threads
connections
I/O
queue depth
Db2 contention
CICS MXT
WLM
E essa é uma das grandes vantagens pedagógicas de estudar testes pensando em mainframe.
O mainframe sempre viveu no mundo onde:
funcionalidade e capacidade são problemas diferentes.
🐒 CHAOS ENGINEERING — Dr. Strangelove finalmente assume o comando
Chaos Engineering parece uma ideia de alguém que bebeu café demais:
vamos quebrar deliberadamente coisas para ver o que acontece.
Exemplo:
derrube um serviço
ou:
adicione latência
ou:
bloqueie acesso ao banco
ou:
mate uma instância
e observe.
A pergunta não é:
o sistema funciona?
A pergunta é:
o sistema continua se comportando
de maneira aceitável quando algo falha?
No mundo COBOL podemos traduzir a ideia para:
Db2 indisponível
MQ indisponível
arquivo faltando
arquivo cheio
dataset em uso
VSAM file status diferente de 00
transaction timeout
deadlock
CICS region indisponível
Sistemas empresariais não são construídos apenas para o mundo feliz.
Eles precisam sobreviver ao mundo real.
🦕 TESTANDO BATCH — o capítulo que os diagramas modernos quase sempre esquecem
Agora chegamos à terra natal do COBOL.
Imagine:
JOB001
↓
gera arquivo
↓
JOB002
↓
atualiza Db2
↓
JOB003
↓
manda MQ
↓
JOB004
↓
gera relatório
Você precisa testar:
JCL
PROC
COND
IF/THEN/ELSE
GDG
DISP
datasets
SORT
IDCAMS
restart
checkpoint
commit
rerun
Exemplo:
STEP010 RC=0
STEP020 RC=4
O STEP030 deveria rodar?
Depende.
E se:
STEP020 RC=8
?
E se o arquivo estiver vazio?
E se houver registro duplicado?
E se o job cair depois de atualizar metade da tabela?
Você consegue reiniciar?
O processamento é idempotente?
Esse último termo merece atenção.
🔁 Idempotência
Significa, simplificando:
executar novamente não deve causar destruição adicional.
Imagine pagamento:
PAGA R$100
Job cai.
Operador reinicia.
Se o programa pagar novamente:
R$200 enviados
temos um pequeno incidente.
Se repetirmos 300 mil registros...
temos reunião com vice-presidente.
🤖 AGORA A IA ENTRA NA SALA DE GUERRA
Chegamos a GitHub Copilot, ChatGPT, Claude, Cursor, Qodo e outros.
Essas ferramentas conseguem ajudar a:
gerar testes
encontrar edge cases
criar mocks
produzir dados
documentar
explicar erros
analisar cobertura
sugerir cenários
Você pode entregar:
IF WS-SALDO >= WS-SAQUE
SUBTRACT WS-SAQUE FROM WS-SALDO
END-IF
e perguntar:
Quais casos devo testar?
A IA provavelmente sugerirá:
saldo maior
saldo igual
saldo menor
saque zero
saque negativo
saldo zero
valor máximo
Isso economiza muito tempo.
Mas existe uma pegadinha digna de Stanley Kubrick.
☢️ IA gera o código. IA gera o teste. Tudo passa.
Imagine:
IA interpreta requisito errado
↓
gera implementação errada
↓
IA usa a mesma interpretação
↓
gera teste errado
↓
PASS
Temos então uma maravilha tecnológica:
um erro perfeitamente documentado, testado, automatizado e aprovado pelo pipeline.
Essa talvez seja uma das grandes questões da engenharia assistida por IA.
Quanto mais fácil fica gerar código, mais importante fica validar intenção.
🧠 O programador do futuro precisará responder menos “como?” e mais “o quê?”
Antes:
Como escrevo este teste?
Agora uma IA pode escrever boa parte dele.
A pergunta mais importante passa a ser:
O QUE precisa ser testado?
E principalmente:
O QUE ninguém lembrou de testar?
A experiência começa exatamente aí.
Um programador iniciante testa:
usuário fez tudo certo
Um programador experiente pergunta:
usuário clicou duas vezes?
Depois:
a rede caiu no meio?
Depois:
a mensagem chegou duplicada?
Depois:
o token expirou?
Depois:
Db2 deu deadlock?
Depois:
o job reiniciou após commit parcial?
A maturidade em testes não consiste em escrever mais ASSERT.
Consiste em imaginar mais maneiras pelas quais a realidade pode destruir nossas suposições.
🛠️ PASSO A PASSO PARA O COBOLISTA INICIANTE
Vamos transformar tudo em um roteiro prático.
Passo 1 — descubra a regra
Antes de testar:
ENTRADA
PROCESSAMENTO
SAÍDA
Exemplo:
SALDO = 1000
SAQUE = 300
SALDO FINAL = 700
Passo 2 — teste o Happy Path
Comece pelo comportamento esperado.
saldo suficiente
valor válido
cliente válido
Passo 3 — teste fronteiras
Se a regra diz:
IDADE >= 18
teste:
17
18
19
Essa pequena técnica encontra uma quantidade absurda de erros.
Passo 4 — teste entradas ruins
zero
negativo
nulo
branco
máximo
mínimo
duplicado
formato inválido
Passo 5 — teste integrações
Pergunte:
e se Db2 falhar?
e se VSAM retornar file status 23?
e se MQ estiver indisponível?
e se CICS devolver erro?
Passo 6 — teste restart
Principalmente batch.
Pergunte:
se cair no meio,
consigo continuar?
Passo 7 — teste segurança
Pergunte:
quem pode executar?
quem pode ver?
quem pode alterar?
Passo 8 — teste carga
Pergunte:
funciona com uma transação?
Depois:
e com 10 mil?
Passo 9 — observe produção
Esse ponto é frequentemente esquecido.
Produção ensina.
Logs, abends, SMF, RMF, CICS statistics, Db2 traces e incidentes mostram situações que talvez ninguém tenha imaginado em laboratório.
Cada incidente deveria produzir, quando possível:
novo conhecimento
↓
novo teste
🎁 EASTER EGGS PARA QUEM CHEGOU ATÉ AQUI
Primeiro:
Dr. Strangelove é uma referência óbvia ao filme de Stanley Kubrick:
Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb.
Nossa versão poderia ser:
How I Learned to Stop Worrying and Love the Test Suite.
Segundo:
Se você encontrar um programador COBOL dizendo:
RC=0, então está certo.
não discuta.
Ofereça café.
Depois pergunte delicadamente:
“Mas você conferiu o arquivo de saída?”
Terceiro:
O verdadeiro teste de integração de qualquer sistema corporativo acontece sexta-feira às 17h43 quando alguém diz:
“É só uma alteração pequena.”
Quarto:
Todo programador algum dia conhece este comando psicológico:
RERUN
Passou na segunda vez?
Ótimo.
Agora você ganhou um problema muito pior.
☕ REGRA BELLACOSA Nº 1
Nunca confunda:
JOB TERMINOU
com:
PROCESSAMENTO CORRETO
Nunca confunda:
TESTE PASSOU
com:
SISTEMA ESTÁ CORRETO
Nunca confunda:
100% COVERAGE
com:
100% CONFIANÇA
E nunca confunda:
IA GEROU 47 TESTES
com:
ALGUÉM ENTENDEU O RISCO.
🧨 A grande conclusão: Testing não é sobre código
No fundo, Testing é engenharia de incerteza.
Estamos tentando responder:
Quanto sabemos sobre o comportamento deste sistema?
Depois:
O que ainda não sabemos?
E finalmente:
Quanto custa descobrir isso somente em produção?
Essa última pergunta muda tudo.
Um bug descoberto durante Unit Test talvez custe minutos.
Durante Integration Test, horas.
Durante homologação, dias.
Depois da implantação, talvez semanas.
Depois de afetar 500 mil clientes...
PowerPoint.
War Room.
Conference Call.
RCA.
Executivos.
Compliance.
Auditoria.
E alguém inevitavelmente perguntará:
Como nossos testes não pegaram isso?
A pergunta quase nunca possui resposta simples.
Porque sistemas reais não são apenas código.
São:
código
+
dados
+
infraestrutura
+
rede
+
configuração
+
segurança
+
operações
+
processos
+
humanos
É por isso que nenhum teste isolado consegue provar que o sistema inteiro é perfeito.
A Pirâmide de Testes, o Testing Trophy, Mutation Testing, Security Testing, Performance Testing e Chaos Engineering são maneiras diferentes de iluminar regiões diferentes da escuridão.
E isso nos leva à talvez mais importante transformação trazida pela inteligência artificial.
Durante décadas, programadores foram valorizados em grande parte por sua capacidade de produzir código.
Agora produzir código está ficando barato.
Muito barato.
Uma IA consegue produzir em segundos aquilo que um desenvolvedor levaria horas para digitar.
Mas produzir confiança continua caro.
Porque alguém precisa entender:
qual é a regra?
qual é o risco?
qual é a exceção?
qual é a fronteira?
qual comportamento seria perigoso?
qual falha é aceitável?
qual falha é catastrófica?
E isso não é simplesmente programação.
Isso é julgamento.
Talvez o programador COBOL de 2030 escreva muito menos código manualmente.
Talvez peça:
“Gere um programa COBOL para esta regra.”
A IA produzirá.
Depois:
“Gere os testes.”
A IA produzirá.
Mas alguém ainda precisará olhar para tudo aquilo e fazer a pergunta que nenhum compilador consegue responder sozinho:
Estamos testando aquilo que realmente importa?
E, quando você chegar a esse ponto, terá deixado de ser apenas alguém que escreve COBOL.
Terá começado a pensar como engenheiro de sistemas.
Em algum lugar distante, o JES2 imprimirá:
MAXCC=0000
Você olhará para a tela.
Não comemorará imediatamente.
Tomará um gole de café.
Abrirá o output.
Conferirá os registros.
Verificará os totais.
Examinará o SQLCODE.
Confirmará os datasets.
E somente então dirá:
— Agora podemos conversar.
Dr. Strangelove sorrirá.
O mainframe continuará funcionando.
E ninguém precisará apertar o botão vermelho.
CHANGE REQUEST CLOSED.
INCIDENT NOT FOUND.
CAFÉ CONSUMIDO COM SUCESSO.
CÂMBIO FINAL.
