Anda o caminho do usuário, não o happy path do código

Esse é o princípio anti-IA-preguiçosa. É fácil "testar" algo rodando uma vez pelo caminho que o código foi escrito pra aguentar. Isso não é testar — é só rodar. Usuários de verdade pausam, leem labels errado, clicam no lugar errado, voltam depois esquecendo o contexto, chegam com expectativas de outros produtos.

Antes de chamar algo de pronto, simule pelo menos três usuários distintos tentando a mesma tarefa:

1. O especialista impaciente — conhece o domínio, quer entrar e sair, nota cada clique desperdiçado.
2. O recém-chegado hesitante — não conhece o domínio, precisa de labels e confirmações, vai abandonar se ficar confuso por mais de 10 segundos.
3. O usuário recorrente — usou a feature uma vez semana passada, esqueceu o contexto, precisa se reorientar rápido.

Os três têm que conseguir completar a tarefa. Se um deles não consegue, a feature não está pronta.

Sinal de violação

O fixture de teste da feature é exatamente o dado que o autor tinha em mente enquanto escrevia. Ou: você consegue descrever "o jeito certo de usar" em uma frase — o que significa que você desenhou pra exatamente um perfil de usuário.

Contra-sinal

Você consegue nomear três jeitos distintos como pessoas vão abordar a feature e você garantiu que cada um funciona. Você achou pelo menos um caso "eu nunca faria isso" que um usuário absolutamente vai fazer.

Bom exemplo

Um fuzz test que roda cada componente por 20+ cenários realistas — valores de borda, strings vazias, strings longas demais, múltiplos presets de estilo, paleta dark, mobile, pior caso combinado. Simulação de usuário no nível do código.

Mau exemplo

Qualquer feature enviada com apenas o path "valores default + viewport desktop + paleta light" verificado.