Como pedir testes automatizados ao GPT-6 Astra que pegam bug de verdade (e não só cobertura)

Tem um tipo de teste que é pior do que teste nenhum: aquele que passa 100%, deixa a barrinha de cobertura verdinha e não pega bug nenhum

A OpenAI lançou o GPT-6 Astra em 3 de setembro de 2026, em preview limitado no mesmo dia do anúncio, apresentado como seu modelo mais capaz para trabalho de ponta a ponta, incluindo engenharia de software

Mas modelo bom não conserta pedido ruim

Quando você digita "cobre esse arquivo com testes", o único contrato que o modelo tem é o próprio código, e ele vai fazer a coisa mais óbvia do mundo: transformar o que o código FAZ em asserção, inclusive o bug

Aqui o jogo vira: neste post tu monta o pedido a partir do comportamento esperado e dos casos de borda, e depois revisa o que voltou pra não aprovar teste decorativo

Bora?

O que você precisa antes de pedir o teste

Primeiro o acesso, que é onde a galera se perde

Na API, o identificador é gpt-6-astra, definido no campo model de uma requisição da Responses API

{
  "model": "gpt-6-astra",
  "reasoning": { "effort": "high" },
  "input": "..."
}

No ChatGPT pago a história é outra: em 7 de setembro de 2026, o rollout nas superfícies Work e Codex passou de faseado para concluído para usuários Plus e Business, enquanto na janela de chat comum o topo continua sendo o GPT-5.6 Sol

Ou seja: se tu abriu o chat normal e não achou o Astra, não é bug teu 🙂

Custo pra colocar na conta: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída

Parece detalhe, mas muda o desenho do pedido: mandar o módulo inteiro é barato, receber 40 arquivos de teste inflados é que pesa

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Janela de contexto: 1.050.000 tokens no total, até 922.000 de entrada e 128.000 de saída

Isso é MUITO espaço

Dá pra mandar o módulo inteiro mais a suíte de testes que já existe, e é exatamente isso que tu quer fazer, porque o modelo precisa ver o que já está coberto pra não te devolver dez testes gêmeos

Esforço de raciocínio: o parâmetro é reasoning.effort na Responses API ou reasoning_effort no Chat Completions, e ele aceita low, medium, high, xhigh e max

Tome cuidado com um detalhe: o nível none NÃO é suportado no Astra

Se tu tinha isso hardcoded de um modelo anterior, vai quebrar

No Codex CLI, modelo e esforço não vão no comando, ficam no config.toml, nas chaves model e model_reasoning_effort

E tem o pré-requisito humano, o que ninguém quer fazer: escrever o comportamento esperado antes de abrir o chat

Cinco linhas em português já bastam

Sem isso, o resto do post não funciona, porque o modelo vai continuar tendo só a implementação como fonte da verdade

Passo a passo: montando o pedido que gera teste que pega bug

1. Escreva o contrato em linguagem natural, antes de mostrar qualquer código

Entradas válidas, saída esperada, e principalmente o que é ERRO

Contrato da função aplicarDesconto(valor, cupom):
- valor: número maior que zero, em centavos
- cupom: string de 6 caracteres OU nulo
- retorna: valor final em centavos, nunca negativo
- erro: cupom expirado deve lançar CupomInvalido, não retornar o valor cheio
Ainda NÃO escreva testes. Só confirme se o contrato está ambíguo em algum ponto.

O erro comum deste passo: colar o código junto do contrato

Se o código entra agora, o modelo ancora nele e passa a descrever a implementação com outras palavras

2. Liste os casos de borda você mesmo, na mão

Vazio, nulo, limite superior, limite inferior, duplicado, fuso horário, concorrência, entrada maliciosa

É chato, leva três minutos e é o que separa suíte de verdade de enfeite

O erro comum deste passo: achar que o modelo vai lembrar do caso de borda que só existe no seu domínio, tipo aquele cliente legado que ainda manda o campo em branco em vez de nulo

3. Peça a LISTA de casos antes de uma linha de teste

Essa é a etapa que quase todo mundo pula, e é ela que coloca revisão humana no meio do fluxo

Com base no contrato acima e nesta lista de bordas que eu já mapeei, derive casos de borda ADICIONAIS.
Devolva apenas uma lista numerada: caso, entrada, saída esperada, e por que ele pega um bug real.
Não escreva código de teste ainda.

Aí tu lê, corta o que é fantasia e aprova

O erro comum deste passo: aprovar a lista batendo o olho

Se entrou caso errado aqui, sai teste errado lá na frente, e teste errado é pior porque ele DÁ CONFIANÇA

4. Agora sim peça os testes, um por comportamento

Um teste por regra, com nome que descreve a regra e não o método

Escreva um teste para cada item aprovado da lista.
Regras:
- um comportamento por teste, sem asserções empilhadas
- o nome do teste descreve a REGRA de negócio, não o nome do método
- nada de mock na lógica que está sendo testada

O erro comum deste passo: aceitar testAplicarDesconto_1, testAplicarDesconto_2

Nome ruim é sintoma: quer dizer que o teste nasceu do método, não da regra

5. Exija o teste falhando primeiro

Pergunta simples e devastadora:

Para cada teste, diga qual linha da implementação eu teria que quebrar para ele falhar.
Se você não conseguir apontar essa linha, marque o teste como frágil.

Teste que não sabe o que ele quebra é teste que não protege nada

6. Calibre o escopo, porque o Astra exagera

A orientação oficial da OpenAI avisa que o Astra tende a ser minucioso em testes antes de considerar a tarefa concluída, e que ele pode testar mais amplamente do que o necessário

A recomendação da própria casa é calibrar os testes ao tamanho e ao risco da mudança, e instruir o modelo a reexecutar testes apenas quando novas falhas ou pendências justificarem

Esta mudança é pequena e de baixo risco: rode só a suíte do módulo afetado.
Reexecute os testes apenas se aparecerem novas falhas ou pendências.

O erro comum deste passo: deixar solto e ver o modelo rodando a suíte inteira em loop, queimando token de saída a US$ 50 por milhão

7. Exija validação de verdade no fim

A documentação oficial recomenda instruir o modelo a validar as mudanças com testes e a conferir os patches, porque ferramentas como apply_patch podem retornar Done mesmo em caso de falha

Leia de novo: Done mesmo em caso de falha

Antes de dar a tarefa por concluída: confira o patch aplicado arquivo por arquivo
e rode os testes de unidade e integração. Não confie no retorno da ferramenta.

Esse mesmo cuidado vale quando ele mexe no código de produção pra fazer o teste passar, que é a receita clássica de corrigir um bug e quebrar outra coisa

Como o pedido muda conforme o tipo de código

A estrutura é sempre a mesma, o que muda é a lista de bordas

Função pura de cálculo:

Aqui o inimigo é número

Inclua bordas numéricas: zero, negativo, máximo do tipo, arredondamento de meio centavo,
divisão que gera dízima e acúmulo de erro em soma repetida.

Endpoint de API:

O contrato não é só a resposta feliz

Cubra: payload sem campo obrigatório, tipo errado no campo, requisição sem autenticação,
token válido de outro usuário, e a mesma requisição enviada duas vezes (idempotência).

Regra de negócio com data:

O clássico que só explode em produção às 21h de domingo

Cubra: virada de mês, virada de ano, 29 de fevereiro, horário salvo em UTC e exibido em -03,
e o caso do usuário em fuso diferente do servidor.

Código legado sem contrato escrito:

Aqui inverte a ordem, porque não existe contrato pra mostrar

Leia este módulo e escreva o comportamento OBSERVADO em português, em forma de lista.
Marque com a palavra SUSPEITO tudo que parecer bug e não regra.
Não escreva testes ainda.

Tu valida a lista, separa regra de bug e SÓ ENTÃO isso vira teste

Se pular essa validação, tu congela o bug em forma de asserção pra sempre

E um aviso pra quem for pedir teste de entrada maliciosa: o Astra atingiu o nível Crítico de capacidade em cibersegurança, e a versão liberada para pagantes é restrita, recusando determinados pedidos nessa área

Ou seja, pedido muito agressivo nessa direção pode simplesmente voltar recusado

Como revisar os testes gerados sem aprovar o que só repete a implementação

Teste tautológico é aquele que afirma que o código faz o que o código faz

Ele passa sempre, inclusive quando está tudo errado

1. Procure a asserção espelho

Se a linha do teste parece a linha da implementação traduzida, é espelho

O valor esperado tem que vir do CONTRATO, escrito à mão, não calculado do mesmo jeito que a função calcula

2. Cace o mock que engoliu a lógica

Mock de banco, de HTTP e de relógio: beleza

Mock justamente da regra que está sob teste: isso é teste de mock, não do seu código

3. Rejeite asserção de "não explodiu"

Teste que só verifica que nenhuma exceção foi lançada não verifica nada

Exige valor esperado ou exige a exceção específica

4. Faça o teste da regra invertida (esse é o definitivo)

Quebre a regra de propósito no código: inverta um sinal, troque >= por >, remova a validação

Rode a suíte

Se NADA falhar, tu acabou de descobrir que aquele bloco de testes é decoração

O erro comum deste passo: fazer isso em um teste só

Faça nos três ou quatro testes que protegem a regra mais cara do sistema, que é onde o prejuízo mora

5. Peça a revisão em prompt separado, sem o histórico

Se tu pedir revisão na mesma conversa, o modelo defende o que ele acabou de escrever

Abra do zero, entrega só o código e a suíte, e dá o papel de crítico:

Você é um revisor cético. Para cada teste desta suíte, diga se ele falharia caso a regra
de negócio correspondente fosse violada. Aponte testes tautológicos, mocks que substituem
a lógica sob teste e asserções que apenas repetem a implementação.

6. Receba a revisão em formato revisável

O Astra mantém na API os recursos que já existiam no GPT-5.6, incluindo Structured Outputs, streaming, chamada programática de ferramentas, orquestração multiagente, prompt caching, raciocínio persistido e compactação

Usa Structured Outputs aqui: um item por teste, com veredito e justificativa, e tu revisa uma tabela em vez de ler três páginas de texto corrido

É o mesmo raciocínio que vale pra pedir revisão de código no seu diff: saída estruturada é o que torna a resposta auditável

Fixando a regra no projeto: AGENTS.md, skills e Codex

Repetir esse prompt gigante toda sessão é insustentável, né?

Então fixa no projeto

1. Coloque as regras de teste no AGENTS.md

A orientação oficial afirma que o Astra é mais sensível a instruções vindas de skills e do AGENTS.md, e que ele tende a fazer mais perguntas de esclarecimento quando a resposta muda o resultado

Isso é ótimo: a pergunta chata dele no começo é o que evita o teste errado no fim

2. Aproveite o scaffold e commite

O Codex cria um scaffold de AGENTS.md que pode ser refinado e commitado pra valer nas próximas sessões, funcionando como substituto das instruções embutidas do Codex

Ou seja: tu escreve uma vez, o time inteiro herda

Algo assim já resolve boa parte:

## Testes
- teste nasce do contrato de negócio, nunca da implementação
- um comportamento por teste, nome descreve a regra
- proibido mockar a lógica sob teste
- antes de concluir: conferir o patch e rodar unidade + integração

3. Separe o agente que escreve do agente que revisa

No config.toml ficam model e model_reasoning_effort, e subagentes aceitam os seus próprios no arquivo do agente customizado

model = "gpt-6-astra"
model_reasoning_effort = "high"

Aí tu monta um subagente dedicado a revisar teste com esforço mais alto, tipo xhigh, e deixa o de escrever mais leve

A orquestração multiagente e o raciocínio persistido estão aí justamente pra isso: quem escreve não é quem aprova

O erro comum deste passo: subir tudo pra max "por garantia"

Token de saída custa US$ 50 por milhão, e revisão boa vem da separação de papéis, não do esforço no talo

4. Conte com as notas persistentes

No Codex, o Astra consegue manter anotações entre janelas de contexto, preservando detalhes acumulados em vez de comprimir tudo num resumo único

Na prática, aquele caso de borda esquisito que tu explicou no início da sessão tem chance de sobreviver até o fim dela

Vídeo do canal

Avaliar ferramenta de IA na prática é sempre o mesmo exercício: define o critério antes, roda o comparativo, olha o resultado com ceticismo

Pra começar do zero nesse tipo de avaliação, este vídeo do canal coloca duas ferramentas de geração de imagem frente a frente e mostra como chegar num veredito olhando o resultado:

O próximo passo

A inversão do post é essa: prompt bom descreve comportamento e borda, prompt ruim descreve arquivo

E a revisão humana não é burocracia, é a etapa que decide se aquele teste vale alguma coisa ou se é só verde na tela

Próximo passo concreto, hoje ainda:

• escolhe UMA função crítica do projeto
• escreve o contrato dela em cinco linhas
• roda o fluxo dos sete passos
• quebra a regra de propósito e confirma que a suíte grita
• commita a regra no AGENTS.md

E sobre o modelo em si, um número pra contextualizar

O Terminal-Bench 4.0 avalia agentes em engenharia de software, configuração de sistema e análise de dados no terminal, e o salto é grande

Mesmo assim, a revisão continua sendo sua 😀

até o próximo post!