Coding agent que conserta o teste: o gate que pega asserção afrouxada e @Disabled no diff

A tarefa era simples: um teste vermelho, um bug em produção. O coding agent devolve a branch com mvn test verde, o Surefire grava um TEST-*.xml com failures="0" errors="0", e o recibo de execução passa. Aí você abre o diff e vê que o arquivo alterado foi o teste. O assertEquals(110, ...) virou assertTrue(... >= 0), ou ganhou um @Disabled em cima. O agente consertou a suíte sem encostar em produção.

O objetivo aqui é um gate local, em Python stdlib, que reprova esses diffs e aprova a correção honesta. Ele cruza duas coisas que já estão no disco: o git diff entre o commit base e o HEAD, separando src/test de src/main, e os atributos do XML do Surefire, incluindo o skipped, que um recibo baseado só em falhas ignora.

Versões usadas

O demo usa JUnit Jupiter 6.1.3 (a versão estável atual, importada pelo junit-bom) com maven-surefire-plugin 3.6.0, maven-compiler-plugin 3.16.0, Temurin 25.0.4 e Maven 3.9.12. O User Guide do JUnit 6.1.3 pede Java 17 ou superior em runtime, então o JDK 25 está coberto. Ficaram de fora o compiler 4.0.0-beta-5 (é o latest do Central, mas ainda é beta) e o 6.2.0-SNAPSHOT que aparece no seletor de versões do guia. A página de uso do Surefire ainda mostra junit-jupiter-engine 5.9.1 num exemplo. Aquilo é ilustração antiga e não deve ser copiado.

<properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <maven.compiler.release>25</maven.compiler.release>
</properties>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.junit</groupId>
      <artifactId>junit-bom</artifactId>
      <version>6.1.3</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>
<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.16.0</version>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>3.6.0</version>
    </plugin>
  </plugins>
</build>

O fixture: withTax devolve 100 onde o teste espera 110

A produção tem um método só, com bug de propósito: devolve o valor sem imposto.

package academy.devdojo.pricing;

public final class Price {
  private Price() {}

  /** amountCents + taxPercent%; initial bug: returns amountCents without tax. */
  public static int withTax(int amountCents, int taxPercent) {
    return amountCents;
  }
}

O teste está certo e é forte:

package academy.devdojo.pricing;

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.Test;

class PriceTest {
  @Test
  void withTaxAddsTenPercent() {
    assertEquals(110, Price.withTax(100, 10));
  }
}

No commit base, mvn -B test sai com EXIT 1, Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, e a mensagem é a esperada: AssertionFailedError: expected: <110> but was: <100> em PriceTest.withTaxAddsTenPercent:10. O XML confirma tests=1 failures=1 errors=0 skipped=0.

A partir daí saem quatro branches, todas do mesmo base. A correção honesta mexe só em Price.java:

    return amountCents + amountCents * taxPercent / 100;

As outras três deixam a produção intacta e mexem só no teste. A primeira afrouxa a asserção:

-    assertEquals(110, Price.withTax(100, 10));
+    org.junit.jupiter.api.Assertions.assertTrue(Price.withTax(100, 10) >= 0);

A segunda desliga o teste:

+import org.junit.jupiter.api.Disabled;
 import org.junit.jupiter.api.Test;
 
 class PriceTest {
   @Test
+  @Disabled("agent silenced")
   void withTaxAddsTenPercent() {

A terceira aborta o teste antes de chegar na asserção:

+import static org.junit.jupiter.api.Assumptions.assumeTrue;
 ...
   void withTaxAddsTenPercent() {
+    assumeTrue(false);
     assertEquals(110, Price.withTax(100, 10));

Quatro jeitos de deixar o mvn verde

O base não passou pelo gate porque ele é só o ponto de partida vermelho. As três trapaças terminam em BUILD SUCCESS, e a do assertTrue nem deixa marca no XML: o resultado é idêntico ao da correção honesta, tests=1 failures=0 errors=0 skipped=0. A asserção nova continua verdadeira, já que preço negativo não existe. Só que ela também é verdadeira para 100, que é exatamente o valor errado.

O @Disabled rodou em 0,034 s, o mais rápido dos cinco. É fácil ser rápido quando nada roda.

Por que o recibo de 22/09 não basta

O Recibo Surefire no coding agent resolve outro problema: prova que os testes rodaram, exigindo um TEST-*.xml recente com failures=0 e errors=0. Ele não olha skipped e não olha o diff de src/test. Contra as linhas da tabela, isso dá o seguinte.

O weaken-assert passa porque o XML está limpo. Não há nada a contar, já que o teste rodou e a asserção nova foi satisfeita. A regra do JUnit é clara no guia de tratamento de exceções: "A test fails only if an exception is thrown unexpectedly or if an assertion fails." Uma asserção que nunca falha nunca reprova nada. Pelo mesmo raciocínio, um método com corpo vazio passa, e o próprio guia mostra um succeedingTest() vazio como exemplo de sucesso.

O disable-test passa porque skipped não é failure. O guia sobre desabilitar testes diz que @Disabled "prevents execution of the test method". O guia não diz em que contador isso cai. Neste run, o Surefire gravou skipped=1. O XSD do relatório (versão 3.0.2) tem tests, errors, skipped e failures como atributos obrigatórios e separados. São strings no schema, mas no relatório vêm como inteiros. Ou seja, a suíte tem um teste e zero problemas, desde que ninguém execute esse teste.

O assume-abort passa pelo mesmo caminho. O guia de assumptions diz que a assumption inválida lança TestAbortedException para que o teste seja "aborted instead of marked as a failure". Aqui deu BUILD SUCCESS e skipped=1. Use assumeTrue(false) para reproduzir. assumingThat não aborta o teste, só deixa de executar o lambda, então não serve para este demo.

Também não confunda com Mutation testing com PIT. O PIT mede se a suíte detecta mutantes em produção. Este gate não roda mutante nenhum: ele olha o que mudou no teste e o que o Surefire contou.

O gate: diff de src/test contra src/main, mais o XML

A regra tem duas metades e não usa AST de Java. A primeira lê git diff --name-only <base> <head> -- src/test src/main e os hunks unificados de src/test. A documentação do git diff descreve a forma git diff <commit> <commit> [--] [<path>...] como a que serve "to view the changes between two arbitrary <commit>". É git local e não depende de GitHub. A segunda metade soma tests, failures, errors e skipped de todos os TEST-*.xml.

Versão encurtada do gate.py usado no run:

#!/usr/bin/env python3
"""Fail closed when tests were weakened to go green.

Reads git diffs (unified hunks, not a Java AST) and Surefire TEST-*.xml.
"""
ASSERT_TOKENS = ("assertEquals", "assertTrue", "assertFalse", "assertThat", "assert ")
WEAKEN_TOKENS = ("@Disabled", "assumeTrue", "assumeFalse", "Assumptions.", "Assumptions.abort")


def parse_reports(reports_dir: Path) -> dict:
    files = sorted(reports_dir.glob("TEST-*.xml"))
    if not files:
        raise SystemExit("FAIL: no TEST-*.xml under " + str(reports_dir))
    totals = {"tests": 0, "failures": 0, "errors": 0, "skipped": 0}
    for path in files:
        root = ET.parse(path).getroot()
        for key in totals:
            totals[key] += int(root.attrib[key])
    return totals


def changed_paths(repo: Path, base: str, head: str) -> tuple[set[str], set[str]]:
    names = git(repo, "diff", "--name-only", base, head, "--", "src/test", "src/main")
    test_files = {n for n in names.splitlines() if n.startswith("src/test/")}
    main_files = {n for n in names.splitlines() if n.startswith("src/main/")}
    return test_files, main_files


def hunk_signals(diff_text: str) -> list[str]:
    reasons, minus_asserts, plus_asserts = [], [], []
    in_hunk = False
    for line in diff_text.splitlines():
        if line.startswith("@@"):
            in_hunk = True
            continue
        if line.startswith(("diff ", "index ", "---", "+++")):
            in_hunk = False
            continue
        if not in_hunk:
            continue
        body = line[1:]
        if line.startswith("+"):
            reasons += [f"added {t}" for t in WEAKEN_TOKENS if t in body]
            if any(t in body for t in ASSERT_TOKENS):
                plus_asserts.append(body.strip())
        elif line.startswith("-"):
            if any(t in body for t in ASSERT_TOKENS):
                minus_asserts.append(body.strip())
    for old in minus_asserts:
        if old not in plus_asserts:
            reasons.append(f"assertion removed or replaced: {old}")
    return reasons


def main() -> int:
    # args: --base --head --reports-dir [--repo] [--allow-test-only --reason TEXT]
    # ...
    reports = parse_reports(Path(args.reports_dir))
    override = load_override(repo, args)  # --allow-test-only --reason, or file TEST_WEAKENING_OK
    problems = []
    if reports["failures"] != 0 or reports["errors"] != 0:
        problems.append(f"surefire failures={reports['failures']} errors={reports['errors']}")
    if reports["skipped"] > 0:
        problems.append(f"skipped={reports['skipped']} (this fixture must not skip)")
    test_files, main_files = changed_paths(repo, args.base, args.head)
    signals = hunk_signals(git(repo, "diff", args.base, args.head, "--", "src/test"))
    if test_files and not main_files and signals:
        problems.append(
            "src/test changed without src/main and weakening tokens in hunks: "
            + "; ".join(signals)
        )
    if override and reports["failures"] == 0 and reports["errors"] == 0:
        print(f"OVERRIDE reason={override}")
        return 0
    if problems:
        for item in problems:
            print("FAIL:", item)
        return 1
    if reports["tests"] <= 0:
        print("FAIL: tests=0")
        return 1
    print("PASS")
    return 0

O resultado em cada branch:

• honest-fix: o diff de src/test contra o base tem 0 bytes, o --name-only lista só src/main/java/academy/devdojo/pricing/Price.java e o XML está zerado. EXIT 0.
• weaken-assert: só PriceTest.java mudou, e a linha - com assertEquals(110, Price.withTax(100, 10)); não reaparece igual em nenhuma linha +. EXIT 1, com o motivo "src/test changed without src/main" mais "assertion removed or replaced".
• disable-test: skipped=1 e added @Disabled no hunk. EXIT 1.
• assume-abort: skipped=1 e added assumeTrue. EXIT 1.

O mesmo critério de linha - sem + correspondente pega quem apaga a asserção inteira ou troca o 110 por 100. Esses dois casos não estão entre os commits executados. Vêm da regra, não do run.

A correção é uma só: o gate reprovou, a tarefa não está concluída. O agente recebe o stdout do gate e volta a trabalhar. O que preservar para observar depois é o diff base..HEAD de src/test e src/main, o stdout do gate e o exit code, como artefatos da tarefa ou do job. Quando alguém perguntar por que aquele PR nunca foi aberto, a resposta está nesses três arquivos, não no transcript.

No CI e no fim da tarefa do agente

Em GitHub Actions, um step run: basta. A sintaxe de workflow define steps[*].run como comando executado no shell do runner. O YAML abaixo é ilustração e não foi executado em GitHub neste run:

- name: mvn test
  run: mvn -B test
- name: test-weakening-gate
  run: python3 gate.py --base origin/master --head HEAD --reports-dir target/surefire-reports

O checkout precisa conter o commit base. Se origin/master não existir no clone, o git diff falha e o script sai com erro. Pelo menos falha fechado.

No agente, a mesma checagem vira política local do harness: a tarefa só é marcada como concluída se o gate sair com exit 0. Nenhum vendor oferece isso pronto. É um script e um exit code:

mvn -B test
python3 gate.py --base "$BASE" --head HEAD --reports-dir target/surefire-reports > gate.out
echo "gate_exit=$?" >> gate.out
git diff "$BASE" HEAD -- src/test src/main > task.diff

Atenção: git diff "$BASE" HEAD compara commits. Mudança que o agente deixou sem commitar no working tree não entra nessa comparação, então o commit precisa vir antes do gate.

O falso positivo: refactor só de teste

A regra "mudou src/test sem mudar src/main" pega trabalho legítimo: renomear método de teste, extrair helper, trocar assertEquals por uma asserção equivalente escrita de outro jeito. Para isso existe o override com motivo explícito. No run, a branch do @Disabled com --allow-test-only --reason "test-only refactor accepted in review" saiu com EXIT 0. O arquivo TEST_WEAKENING_OK na raiz, com o motivo na primeira linha não vazia, tem o mesmo efeito. O override não perdoa failures nem errors: se o XML mostrar falha, o gate reprova com ou sem motivo.

A tese continua de pé para PRs só de teste, desde que o motivo venha de uma pessoa que leu o diff e fique registrado no PR. O que não pode é o agente escrever o próprio motivo e aprovar a si mesmo.

Vale conhecer dois limites do gate do jeito que ele está. A regra skipped > 0 é deste fixture. Num repositório com skips legítimos, ela vira ruído e pede uma comparação com a contagem do base, que este script não faz. E a parte do diff só dispara quando src/main não mudou. Um agente que muda um comentário em Price.java e afrouxa o assert no mesmo commit escapa dessa metade da regra. O skipped ainda pega o @Disabled, mas o assertTrue(... >= 0) só é pego na revisão humana.

Quando adotar

A DevDojo adotaria o gate quando agentes já abrem PRs sozinhos e a suíte do módulo não tem skips esperados. Nesse cenário ele custa um script stdlib e pega exatamente as três trapaças da tabela, que nenhum recibo de failures=0 errors=0 enxerga. Hora de recuar ou ajustar a regra: quando o override começa a aparecer em metade dos PRs, ou quando os skips legítimos tornam o skipped > 0 inútil. Nos dois casos o gate virou carimbo.

Próximo passo: rode o gate.py na branch do agente, depois do commit e antes de abrir o PR, com --base apontando para o commit de onde a tarefa partiu. Se der EXIT 1, devolva o gate.out ao agente e não abra o PR.