salve o/
outro dia esbarrei num artigo meu sobre testes em vuejs. coisa de uns bons anos atrás. o exemplo era um componente de quantidade no carrinho de compras, dois botões e um input. o tipo de coisa simples que muda de framework a cada cinco anos, mas continua levantando a mesma pergunta: o que vale a pena testar?
a resposta que eu dava lá atrás era — testa o contrato, não a implementação. trata o componente como caixa preta, simula a interação do usuário e confere se a saída bate.
essa resposta sobreviveu a tudo.
2012 e o cheiro de queimado
comecei a trabalhar como dev lá por 2012. a guerra dos browsers ainda tava quente — vc abria o devtools do ie e sentia um cheiro de queimado, como se o próprio navegador estivesse te pedindo pra desistir. jquery reinava absoluto. angular 1 tava chegando com aquele two-way data binding que parecia bruxaria.
e teste? teste era coisa de backend. frontend era “abre no browser e vê se funciona”.
a real é que a maioria dos projetos frontend daquela época não tinha um único teste. e a gente dormia bem assim, porque não sabia o que tava perdendo.
a montanha-russa de frameworks
de lá pra cá o ecossistema deu umas três voltas completas. angular virou angularjs virou angular 2+ virou “qual versão a gente tá mesmo?”. react apareceu e mudou a conversa inteira sobre componentização. vue chegou com uma proposta mais suave, ganhou uma comunidade apaixonada. cada ciclo trouxe suas ferramentas de teste junto — karma, jasmine, mocha, jest, vitest, testing library. os nomes mudaram, as apis mudaram, o jeito de configurar mudou.
mas o fundamento ficou parado no lugar.
aquele artigo de vue que eu escrevi usava jest e vue test utils. se eu fosse reescrever hoje, provavelmente usaria vitest e testing library. o setup seria diferente, o import seria diferente, talvez até a sintaxe do componente fosse composition api ao invés de options api. mas o teste em si — monta, clica, confere o valor — seria idêntico. porque o contrato do componente não mudou.
e agora tem ia no meio
essa é a parte que eu acho mais interessante pra refletir. a gente tá vivendo um momento onde agentes de ia escrevem código, revisam pr, geram testes automaticamente. ferramentas como claude code pegam um componente e cospem uma suíte de testes em segundos. mcp conecta modelos de linguagem a qualquer serviço externo como se fosse um npm install da vida — se vc ainda não leu, escrevi sobre isso aqui no blog.
e sabe o que acontece quando vc pede pra uma ia gerar testes sem entender o que deveria ser testado? ela testa implementação. ela testa que o método incrementar existe, que data() retorna o estado inicial. o tipo de teste frágil que quebra quando vc refatora sem mudar comportamento nenhum.
a diferença cabe em duas linhas:
// teste de implementação — frágil
expect(wrapper.vm.incrementar).toBeDefined()
// teste de contrato — resiliente
await user.click(botaoIncrementar)
expect(input).toHaveValue(1)o primeiro quebra se vc renomeia o método. o segundo só quebra se o botão parar de funcionar.
o que sobrevive
treze anos depois de ter começado, o que eu levo comigo é bem simples. as ferramentas mudam o tempo todo — e deveriam mudar, porque o ecossistema tá evoluindo. a guerra dos browsers acabou (mais ou menos). jquery aposentou. frameworks vão e vêm. ia entrou no fluxo de desenvolvimento e não vai sair.
mas a pergunta continua a mesma: dado esse input, o output é o que eu espero?
não importa se o componente é vue 2 com options api, react 19 com server components ou um web component vanilla. não importa se quem escreveu o teste foi vc ou um agente. o que importa é se o teste valida o comportamento que o usuário percebe. o resto é detalhe de implementação — e detalhe de implementação muda na próxima sprint.
aquele bug do artigo original é perfeito pra ilustrar isso. o botão de incrementar resolvia 1 + 1 e devolvia 11, porque o input cuspia texto e o js concatenava ao invés de somar. o teste pegou o problema não porque sabia como o método funcionava por dentro, mas porque simulou o que o usuário faria e conferiu o resultado. caixa preta. contrato respeitado. bug encontrado.
se vc tá começando agora e se sente perdido com a quantidade de coisa pra aprender — frameworks, bundlers, ia, mcp, agentes — respira. a base não muda tão rápido quanto parece. aprende a testar comportamento, não implementação. o resto vc vai trocando conforme o cenário pede.
e se vc já tá na estrada há um tempo, talvez valha revisitar aquele teste antigo que vc escreveu. capaz que o framework já nem exista mais, mas a lógica por trás ainda funcione.
treze anos depois, aquele componente de carrinho continua simples. dois botões, um input e a mesma pergunta de sempre: o que realmente importa aqui?
o framework envelheceu. o princípio não.
to sempre no linkedin, github e bluesky.
vida longa e próspera \o