Ferramenta de Auditoria de UI: Aprendizados e Erros

A linha na parte inferior do relatório dizia:

Registros com descobertas automatizadas: 8/4

Oito em quatro. Mais telas com descobertas do que telas.

Eu escrevi essa ferramenta. Ela mede UIs da web — razões de contraste em relação ao fundo composto real, alvos de toque abaixo de 44px, controles que algo mais está cobrindo, texto cortado pelo seu próprio contêiner. Ela tem 142 testes. Cada um deles passou enquanto imprimia esse número.

Aqui está o que estava por baixo disso, e o que o exercício me ensinou sobre o tipo de bugs que os testes são estruturalmente ruins em detectar.

O contador estava contando o substantivo errado

A correção levou dois minutos: o contador incrementava uma vez por tipo de descoberta enquanto seu rótulo dizia registros. Dois problemas em uma tela contavam duas vezes.

A parte interessante estava uma linha abaixo. O relatório também imprime verificações automatizadas limpas quando uma tela não tem nada errado — e essa decisão foi tomada por uma lista completamente separada:

const qualquerDescoberta = d.horizontalOverflow || d.smallTargets?.length || d.tinyText?.length
  || d.invisibleText?.length || d.lowContrast?.length || d.buttonIssues?.length
  || k.console.length || k.network.length
  || d.coveredControls?.length || d.clippedText?.length || d.coveredByFixed?.length;

Uma lista mantida manualmente do que conta como uma descoberta. O mecanismo havia crescido além disso. Assim, uma tela cujo único problema era um dos novos testes imprimiria a descoberta — e então, logo abaixo, diria que estava limpa.

Ambos vêm de uma única bandeira agora, definida por cada ramo que realmente imprime algo. Não pode se desviar, porque não há mais nada do que se desviar.

Então a mesma forma, mais três vezes

Uma vez que você a viu, começa a encontrá-la.

O teste de alvo de toque construiu seu próprio rótulo. Há uma função shortLabel(el) cuja única função é "que texto uma pessoa lê aqui". O teste de alvo de toque não a chamou; ele carregou sua própria cópia da mesma ideia, escrita anteriormente. É por isso que um elemento select voltou com quebras de linha dentro de seu rótulo enquanto todas as outras descobertas as tinham colapsadas.

A regra de contraste tinha sua própria lista de ícones-fontes. Assim como o código do rótulo. O de contraste conhecia lucide e feather; o de rótulo conhecia nomes de classes como material-symbols-outlined. Cada um perdeu exatamente o que o outro pegou.

A última produziu minha descoberta favorita da rodada. Dois dos três aplicativos relataram rótulos de botões assim:

botão 71x34 — "adicionar Şarkı"
botão 36x34 — "light_mode"

Ícones-fontes colocam o nome do ícone no nó de texto e desenham um glifo sobre ele. Assim, innerText lê o que ninguém vê, e metade dos 45 caracteres do rótulo vai para algo invisível. Rótulos agora ignoram elementos de ícone e mantêm as palavras ao redor deles — e para um botão apenas de ícone, onde não há nada mais para ler, eles recorrem ao nome acessível. O alternador de tema passou de light_mode para Tema değiştir. O relatório acabou sendo mais útil do que era antes do bug existir.

Esses rótulos aparecem em toda a saída. Executado a partir da linha de comando em vez do editor, a ferramenta percorre cada dispositivo e ambos os temas em uma única passagem e escreve uma galeria — um cartão por tela, suas próprias descobertas abaixo dela — então um rótulo ruim é um rótulo ruim em quarenta lugares ao mesmo tempo:

Por que 142 testes não pegaram nada disso

Cada um desses é um bug na relação entre duas partes do código que concordam entre si. O contador concordou consigo mesmo. A lista qualquerDescoberta concordou consigo mesma. Ambos os construtores de rótulos estavam individualmente corretos.

Um teste unitário pergunta "essa função faz o que diz". Nenhuma dessas funções mentiu. O que estava errado era que havia duas delas.

O que os pegou foi executar a ferramenta em algo que ela não havia visto. Não mais testes — uso. Três sites, uma hora, sete defeitos, todos meus.

Os testes que adicionei depois têm uma forma diferente dos que eu tinha. Eles não testam funções; eles comparam dois lados do programa entre si. Um lê os tipos de descobertas que o mecanismo produz e falha se algum consumidor não os imprime. Um lê os comandos npx de cada documento e recusa qualquer um que nomeie um bin em vez de um pacote — porque o comando principal do README, npx -y uisight-mcp, nunca funcionou. uisight-mcp é um bin dentro do pacote uisight, não um pacote próprio. Cada novo usuário enfrentou um 404 no primeiro passo.

Aquele teve um seco