Imagine a seguinte cena: voc\u00ea pede para um assistente de IA gerar uma fun\u00e7\u00e3o de valida\u00e7\u00e3o de CPF, ou um endpoint de API, ou uma rotina de c\u00e1lculo financeiro. O c\u00f3digo chega r\u00e1pido, bem formatado, com nomes de vari\u00e1veis sensatos e at\u00e9 coment\u00e1rios explicativos. Parece pronto. Voc\u00ea cola no projeto, executa manualmente uma ou duas vezes, v\u00ea que “funciona” e segue em frente. Semanas depois, um caso de borda que ningu\u00e9m testou explode em produ\u00e7\u00e3o \u2014 e a investiga\u00e7\u00e3o revela que aquele trecho gerado pela IA nunca foi validado de verdade, apenas validado visualmente.<\/p>\n
Esse cen\u00e1rio se repete com uma frequ\u00eancia preocupante nas equipes que adotaram ferramentas como Claude Code, Cursor, GitHub Copilot ou qualquer outro assistente de gera\u00e7\u00e3o de c\u00f3digo. O problema n\u00e3o \u00e9 a IA ser ruim \u2014 \u00e9 que c\u00f3digo gerado automaticamente precisa ser tratado com o mesmo rigor que c\u00f3digo de um desenvolvedor j\u00fanior no primeiro dia: promissor, mas n\u00e3o confi\u00e1vel at\u00e9 prova em contr\u00e1rio. E “prova em contr\u00e1rio”, em engenharia de software, tem nome: harness de testes.<\/p>\n
Neste artigo vamos construir, passo a passo, um harness de testes pensado especificamente para validar c\u00f3digo gerado por IA, com exemplos em m\u00faltiplas linguagens, estrat\u00e9gias de cobertura e uma estrutura que voc\u00ea pode adaptar ao seu stack \u2014 seja Python, TypeScript, Java, C# ou Delphi.<\/p>\n
Um harness de testes (do ingl\u00eas test harness<\/em>) \u00e9 o conjunto de ferramentas, scripts, mocks, dados de entrada e infraestrutura que permite executar testes automatizados de forma consistente e repet\u00edvel, sem interven\u00e7\u00e3o manual. Pense nele como uma bancada de testes de laborat\u00f3rio: voc\u00ea n\u00e3o testa um componente eletr\u00f4nico apertando fios com a m\u00e3o a cada vez \u2014 voc\u00ea monta uma bancada com mult\u00edmetro, fonte de alimenta\u00e7\u00e3o e oscilosc\u00f3pio configurados uma vez, e depois s\u00f3 troca o componente sob teste.<\/p>\n No contexto de c\u00f3digo gerado por IA, o harness cumpre um papel ainda mais cr\u00edtico do que em desenvolvimento tradicional, por tr\u00eas motivos:<\/p>\n Uma su\u00edte de testes tradicional geralmente \u00e9 escrita pensando no comportamento esperado de c\u00f3digo que voc\u00ea mesmo projetou. Um harness para c\u00f3digo de IA precisa ser mais desconfiado por padr\u00e3o: ele assume que o c\u00f3digo pode estar sutilmente errado mesmo quando “parece” certo, e por isso incorpora camadas adicionais de verifica\u00e7\u00e3o, como testes de propriedades, testes de regress\u00e3o autom\u00e1tica e valida\u00e7\u00e3o de contratos de entrada e sa\u00edda.<\/p>\n Um harness robusto para esse cen\u00e1rio costuma ter quatro camadas:<\/p>\n O primeiro erro comum \u00e9 colar o c\u00f3digo da IA diretamente misturado com o restante da aplica\u00e7\u00e3o. Isso dificulta testar isoladamente. A pr\u00e1tica recomendada \u00e9 sempre gerar c\u00f3digo atr\u00e1s de uma interface ou contrato bem definido, mesmo que a implementa\u00e7\u00e3o venha de um prompt.<\/p>\n Com o contrato definido, o harness testa contra a interface, n\u00e3o contra a implementa\u00e7\u00e3o espec\u00edfica \u2014 o que permite trocar a implementa\u00e7\u00e3o gerada pela IA sem quebrar a su\u00edte de testes.<\/p>\n Pe\u00e7a sempre para a IA listar os casos de borda que ela considerou, e depois adicione os que ela n\u00e3o considerou. Usando Jest<\/a> como exemplo:<\/p>\n Esses testes j\u00e1 pegariam boa parte dos erros t\u00edpicos de implementa\u00e7\u00f5es geradas \u00e0s pressas, como esquecer de tratar CPFs com d\u00edgitos repetidos (um erro cl\u00e1ssico que passa despercebido em revis\u00f5es visuais).<\/p>\n Testes de exemplo fixo cobrem apenas os casos que voc\u00ea imaginou. Testes de propriedades geram centenas de entradas aleat\u00f3rias e verificam invariantes. Em Python, a biblioteca Hypothesis<\/a> \u00e9 a refer\u00eancia:<\/p>\n Se a fun\u00e7\u00e3o gerada pela IA tiver um erro de sinal ou uma divis\u00e3o mal posicionada, o Hypothesis encontra o contraexemplo automaticamente e reporta a entrada exata que quebrou a invariante \u2014 algo praticamente imposs\u00edvel de descobrir s\u00f3 olhando o c\u00f3digo.<\/p>\n Quando o c\u00f3digo gerado envolve acesso a arquivos, rede ou processos do sistema, \u00e9 fundamental execut\u00e1-lo em um ambiente isolado antes de confiar nele. Containers s\u00e3o a ferramenta natural para isso. Um exemplo simples com Docker<\/a>, rodando os testes em um container descart\u00e1vel:<\/p>\n A flag O harness s\u00f3 tem valor real se rodar automaticamente a cada gera\u00e7\u00e3o ou altera\u00e7\u00e3o de c\u00f3digo. Um exemplo de workflow com GitHub Actions<\/a>:<\/p>\n Note o gatilho baseado em \n
Diferen\u00e7a entre Harness e Su\u00edte de Testes Comum<\/h3>\n
Como Funciona: Anatomia de um Harness para C\u00f3digo de IA<\/h2>\n
\n
Passo 1: Isolar o C\u00f3digo Gerado em uma Interface Clara<\/h3>\n
\/\/ contrato.ts\nexport interface ValidadorDocumento {\n validar(documento: string): boolean;\n}\n\n\/\/ gerado-pela-ia.ts\nimport { ValidadorDocumento } from '.\/contrato';\n\nexport class ValidadorCPF implements ValidadorDocumento {\n validar(cpf: string): boolean {\n const numeros = cpf.replace(\/\\D\/g, '');\n if (numeros.length !== 11 || \/^(\\d)\\1{10}$\/.test(numeros)) {\n return false;\n }\n \/\/ l\u00f3gica de valida\u00e7\u00e3o dos d\u00edgitos verificadores...\n return true;\n }\n}\n<\/code><\/pre>\nPasso 2: Testes Unit\u00e1rios com Casos de Borda Expl\u00edcitos<\/h3>\n
import { ValidadorCPF } from '..\/gerado-pela-ia';\n\ndescribe('ValidadorCPF gerado por IA', () => {\n const validador = new ValidadorCPF();\n\n test('rejeita CPF com todos os d\u00edgitos iguais', () => {\n expect(validador.validar('111.111.111-11')).toBe(false);\n });\n\n test('rejeita CPF com menos de 11 d\u00edgitos', () => {\n expect(validador.validar('123.456.789')).toBe(false);\n });\n\n test('aceita CPF v\u00e1lido conhecido', () => {\n expect(validador.validar('529.982.247-25')).toBe(true);\n });\n\n test('rejeita string vazia', () => {\n expect(validador.validar('')).toBe(false);\n });\n\n test('rejeita entrada com caracteres n\u00e3o num\u00e9ricos misturados incorretamente', () => {\n expect(validador.validar('abc.def.ghi-jk')).toBe(false);\n });\n});\n<\/code><\/pre>\nPasso 3: Testes de Propriedades para Cobrir o Que Voc\u00ea N\u00e3o Pensou<\/h3>\n
from hypothesis import given, strategies as st\nfrom validador_gerado_pela_ia import calcular_desconto\n\n@given(preco=st.floats(min_value=0.01, max_value=1_000_000),\n percentual=st.floats(min_value=0, max_value=100))\ndef test_desconto_nunca_e_negativo(preco, percentual):\n resultado = calcular_desconto(preco, percentual)\n assert resultado >= 0\n\n@given(preco=st.floats(min_value=0.01, max_value=1_000_000),\n percentual=st.floats(min_value=0, max_value=100))\ndef test_desconto_nunca_supera_o_preco_original(preco, percentual):\n resultado = calcular_desconto(preco, percentual)\n assert resultado <= preco\n<\/code><\/pre>\nPasso 4: Sandbox de Execu\u00e7\u00e3o Isolada<\/h3>\n
FROM python:3.12-slim\n\nWORKDIR \/app\nCOPY . .\n\nRUN pip install --no-cache-dir -r requirements.txt\n\n# Sem acesso \u00e0 rede durante os testes, sem volumes persistentes montados\nCMD [\"pytest\", \"--maxfail=1\", \"--disable-warnings\", \"-q\"]\n<\/code><\/pre>\ndocker build -t harness-ia .\ndocker run --rm --network none harness-ia\n<\/code><\/pre>\n--network none<\/code> garante que, se o c\u00f3digo gerado tentar fazer uma chamada externa inesperada (um comportamento que \u00e0s vezes aparece quando a IA “inventa” uma depend\u00eancia ou tenta buscar dados de uma API imagin\u00e1ria), o teste falhe de forma controlada em vez de causar efeitos colaterais reais.<\/p>\nPasso 5: Automatizando no Pipeline de CI<\/h3>\n
name: harness-codigo-ia\n\non:\n pull_request:\n paths:\n - 'src\/gerado-por-ia\/**'\n\njobs:\n validar:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n\n - name: Configurar Node\n uses: actions\/setup-node@v4\n with:\n node-version: '20'\n\n - name: Instalar depend\u00eancias\n run: npm ci\n\n - name: Rodar testes unit\u00e1rios e de propriedades\n run: npm test -- --coverage\n\n - name: Verificar cobertura m\u00ednima\n run: npx nyc check-coverage --lines 85 --functions 85 --branches 75\n<\/code><\/pre>\npaths<\/code>: o pipeline dispara especificamente quando arquivos na pasta reservada para c\u00f3digo gerado por IA s\u00e3o alterados, tornando expl\u00edcito que esse c\u00f3digo passa por um crivo mais rigoroso.<\/p>\nExemplo em Outro Ecossistema: Delphi<\/h3>\n