chimera-prove-the-test-discriminates

Um teste de regressão que você nunca viu falhar é um chute. Quebre o código de novo e veja o teste ficar vermelho antes de commitá-lo.

PadrãoProcedência: cleanEstado: activev0.1.0 · Apache-2.0

Conferida por quem revisou e leu o cartão, não reivindicada pelo próprio arquivo. Um cartão que o agente destila durante uma execução que consumiu conteúdo não confiável nasce contaminado e fica retido para revisão antes de alguma vez ser recuperado.

Quando ele vem à mente

escrevi um teste de regressão
corrigi um bug e adicionei um teste
o teste passa, pode subir
adicionando o teste depois da correção

Evite e Verifique são onde costuma estar o valor. Faça é a seção que todo mundo escreve.

O corpo do cartão acima é uma tradução. O original em inglês é o que a CLI importa, o que o agente lê em execução e o que o hash abaixo atesta.

Gatilho

Você corrigiu um bug e escreveu um teste para que ele não volte. O teste passa. Essa é toda a evidência que você tem, e é a mesma evidência que você teria se o teste não afirmasse nada sobre o bug.

Vale de forma mais aguda quando o teste foi escrito depois da correção, porque aí o único código contra o qual o teste já rodou é um código em que o bug já não existe. Vale menos para um teste escrito antes, vermelho, num ciclo de TDD — você já viu aquele falhar, que é o ponto inteiro do ciclo.

Não se aplica a um teste de comportamento genuinamente novo, onde não existe um "antes" para o qual reverter. Ali a checagem discriminante é outra: apague a nova implementação e confirme que o teste falha pela ausência, não pelo bug.

Faça

Identifique a edição exata que constitui a correção — o hunk, não o commit. Se a correção é uma comparação alterada, é essa comparação que você vai desfazer.
Desfaça-a. git stash na correção, ou inverta aquela linha de volta para a forma quebrada, à mão.
Rode apenas o teste novo: pytest tests/test_thing.py::test_the_regression -x.
Leia a falha. Ela precisa ser a sua asserção falhando, com uma mensagem sobre o comportamento — não um SyntaxError, não um erro de coleta, não um ImportError vindo de um arquivo revertido pela metade. Esses são vermelhos pelo motivo errado e não provam nada sobre o teste.
Restaure a correção (git stash pop) e confirme que o mesmo teste agora passa.
Coloque o fato na docstring do teste: o que foi revertido, e como era a falha. A próxima pessoa a mexer neste teste precisa saber que ele algum dia foi exercitado contra o bug.

Evite

Afirmar algo que é verdade nos dois mundos. O formato clássico:


result = parse_config(raw)
assert result is not None
assert "timeout" in result

O bug era que timeout voltava como a string "30" em vez do inteiro 30. As duas asserções valem de qualquer jeito. O que discrimina é aquilo que mudou:

# RIGHT — fails against the buggy code
assert parse_config(raw)["timeout"] == 30
assert isinstance(parse_config(raw)["timeout"], int)

Evite também reverter comentando uma função inteira ou apagando um import para "fazer falhar rápido". Isso produz uma execução vermelha que teria acontecido para qualquer teste do arquivo, então não te diz nada sobre este teste. A reversão precisa ser a correção e apenas a correção.

E evite o quase-acerto em que o teste alcança o código corrigido por um caminho que a produção nunca usa — essa é outra falha, e o card dela é chimera-test-the-wiring-not-the-class.

Verifique

Uma pergunta binária: você viu pessoalmente este teste imprimir uma falha causada pela sua própria asserção, contra o código sem a correção?

Se sim, acabou. Se a resposta for "ele teria falhado", você não checou nada — essa frase é uma previsão produzida pelo mesmo raciocínio que escreveu o teste.

Mecanicamente:

git stash                 # remove the fix
pytest tests/test_x.py::test_regression   # MUST be red, on your assertion
git stash pop             # restore
pytest tests/test_x.py::test_regression   # MUST be green

Vermelho-depois-verde, ambos observados, ou o teste está por provar.

Risco

Algumas correções não podem ser revertidas barato: um upgrade de dependência, uma migration de schema, um arquivo apagado, uma mudança numa biblioteca vendorizada. Forçar uma reversão ali pode custar mais do que o teste vale. O recuo honesto é reconstruir a entrada que costumava quebrá-lo e afirmar o valor específico, e então dizer claramente na docstring que a execução vermelha não foi observada — um teste não provado que admite não estar provado é muito melhor que um que dá a entender que foi checado.

O perigo real deste card é a reversão que você esquece de desfazer. Fazer essa dança numa árvore de trabalho suja é como uma linha rebugada vai parar num commit junto do seu próprio teste de regressão, com a suíte verde porque você restaurou a correção no arquivo errado. Rode git diff antes de commitar, todas as vezes.

E um teste discriminante continua valendo só o quanto você entendeu do bug. Ele prova que o teste pega esta reversão. Não prova que você corrigiu a causa raiz em vez do sintoma, e tratar uma execução vermelho-depois-verde como prova disso é uma afirmação maior do que a evidência sustenta.

Como usar

O cartão é dado. Clone o repositório e importe pelo caminho — o que chega pela rede é tratado como contaminado e fica retido para aprovação, que é o comportamento desejável e a razão de não haver um instalador de uma linha aqui.

$git clone https://github.com/brcampidelli/chimera-agent.git

$chimera skills-import chimera-agent/skills/chimera-prove-the-test-discriminates/SKILL.md

Integridade

SHA-256 do arquivo como publicado. Quem importa pode conferir que o que recebeu é o que esta página mostrou.

90d4bf00eb67055008527ee372153b2637fa2feea601ed6760997eda239f0b76

Leia o cartão no repositório →