A virada contemporânea e a IA

Os fundamentos das camadas e dos tipos são estáveis, mas a prática ao redor deles se moveu bastante desde meados dos anos 2010, e a partir de 2022 ganhou uma camada que não existia. Duas forças explicam quase toda a mudança recente: sistemas deixaram de rodar numa máquina só e passaram a viver distribuídos e em produção contínua, e ferramentas, primeiro de automação, depois de IA, mudaram o custo de cada tipo de teste. Reler o assunto pela régua de confiança sobre custo mostra que não houve revolução de princípio; houve reavaliação de onde a conta fecha.

O fim do test-first como dogma

O marco simbólico da virada foi um desabafo. Em abril de 2014, David Heinemeier Hansson publicou “TDD is dead. Long live testing”, declarando que não escrevia software com o teste primeiro e acusando o fundamentalismo test-first de empurrar o design para arquiteturas contorcidas, cheias de indireção só para permitir o mock. A provocação virou uma série de cinco conversas gravadas entre Kent Beck, Martin Fowler e o próprio DHH, hospedadas no site de Fowler ao longo de maio e junho daquele ano.

Não houve vencedor declarado, e a ausência de veredito foi o veredito. O consenso que sobrou é que código autotestável é valioso, que o TDD é uma técnica dependente de contexto e não um mandamento, e que o problema real era a aplicação dogmática, não a prática. O efeito de médio prazo foi legitimar o recuo do mock pesado e do teste de unidade solitário como padrão universal, e abrir espaço para a virada rumo à integração que o troféu e o favo de mel viriam a codificar. A frase de Kent C. Dodds, de que mockar algo remove toda a confiança na integração entre o que se testa e o que foi mockado, é a moral dessa história dita em uma linha.

Do Selenium ao Playwright

Na automação de navegador, a década foi de troca de guarda. O Selenium reinou por anos e teve seu protocolo, o WebDriver, promovido a recomendação do W3C em 2018, o que consolidou seu lugar como o padrão mais interoperável. Mas a experiência de escrever e manter testes com ele envelheceu mal: esperas explícitas por elementos, fragilidade, cerimônia. Duas ferramentas capturaram a insatisfação. O Cypress, cujo primeiro commit é de 2014 e que abriu ao público por volta de 2017, roda dentro do próprio navegador, no mesmo laço de execução da aplicação, o que dá acesso nativo ao DOM e à rede ao preço de restrições (só JavaScript, dificuldade com múltiplas abas e domínios cruzados). O Playwright, lançado pela Microsoft em janeiro de 2020 por uma equipe vinda do Puppeteer, resolveu os pontos que mais doíam no Selenium: espera automática pela prontidão do elemento, controle do navegador de fora do processo, contextos isolados que baratearam o paralelismo, e suporte real a vários motores de navegador. A direção de 2023 em diante é clara nas pesquisas de uso, Playwright em ascensão firme, Cypress estável, Selenium em retração entre projetos novos, ainda que dominante no legado.

Junto foi o gravador-reprodutor, o antigo Selenium IDE que registrava cliques e os reproduzia. Ele caiu por um motivo estrutural: os seletores gravados são frágeis, quebram à menor mudança de layout, e o fluxo não escala para uma suíte que se possa manter. A crítica se estendeu ao Page Object Model, o padrão que encapsula cada tela numa classe de seletores. O padrão não morreu, mas o excesso, seletores de CSS e XPath acoplados à estrutura interna da página, passou a ser visto como fonte de fragilidade. A alternativa que ganhou tração inverte a mira: localizar elementos como um usuário os enxerga, pelo papel e pelo texto (o botão “Enviar”, o campo rotulado “E-mail”), filosofia que a Testing Library difundiu e que o Playwright embutiu em seus localizadores por papel. É a mesma ideia do princípio de Dodds levada ao seletor:

Quanto mais seus testes se parecem com a forma como seu software é usado, mais confiança eles podem te dar.

Testar para a esquerda e para a direita

Com sistemas em produção contínua, a pergunta “quando testar?” ganhou duas respostas opostas e complementares. Deslocar para a esquerda (shift-left, termo atribuído a Larry Smith por volta de 2001) é antecipar o teste no ciclo: rodá-lo mais cedo, no commit e no pull request, para pegar o defeito quando ele é barato. Deslocar para a direita (shift-right) é o reconhecimento de que nenhum ambiente de teste reproduz a produção de verdade, e que parte da verificação só é honesta lá. Testar em produção deixou de ser confissão de fracasso e virou disciplina, com um instrumental próprio: feature flags que separam o deploy do release e permitem ligar um recurso para uma fração dos usuários, canary releases que expõem a versão nova a uma pequena coorte antes de todos, e monitoração sintética que roda fluxos de usuário contra o sistema vivo o tempo todo.

O braço mais radical do shift-right é a engenharia do caos, nascida na Netflix. O Chaos Monkey, anunciado publicamente em 2011, mata instâncias em produção de propósito, em horário comercial, para forçar o sistema a provar que sobrevive a falhas; a Simian Army ampliou a ideia com outras formas de sabotagem controlada, e a empresa Gremlin, de 2016, transformou “falha como serviço” em produto. A definição que o manifesto Principles of Chaos consagrou vale citar, porque enquadra o caos como teste e não como imprudência:

Engenharia do caos é a disciplina de experimentar sobre um sistema a fim de construir confiança na sua capacidade de suportar condições turbulentas em produção.

O imposto do flaky

Empurrar testes para o topo da pirâmide tem um custo que só aparece em escala, e o Google o mediu. Num texto de 2016, John Micco relatou que, em todo o acervo de testes da empresa, cerca de 1,5% das execuções reportavam um resultado flaky, instável, que passa ou falha sem que o código tenha mudado. Quase 16% dos testes exibiam algum grau de instabilidade, e, o dado mais revelador, cerca de 84% das transições de “passou” para “falhou” observadas envolviam um teste flaky, não um bug real. Um ano depois, Jeff Listfield acrescentou a correlação que fecha o argumento: testes maiores são mais flaky, a instabilidade cresce com o escopo.

Esse é o preço concreto por trás da forma da pirâmide. Um teste que fica vermelho sem motivo corrói a confiança na suíte inteira, porque ensina a equipe a ignorar o vermelho, e um sinal ignorado não vale o custo de existir. A instabilidade se concentra justamente nas camadas largas de cima, ponta a ponta e integração ampla, o que dá mais um motivo, além de velocidade e custo, para não deixá-las inchar. Boa parte do investimento recente em detecção automática de flaky e em re-execução seletiva é uma tentativa de tornar as camadas altas sustentáveis apesar desse imposto.

A cobertura como alvo

Uma prática saiu de moda de vez: exigir cobertura de 100% como meta. A razão amadureceu na comunidade e ecoa o que o teste de mutação já expunha, cobertura mede quais linhas foram executadas, não se algum teste de fato detectaria um defeito nelas. Como indicador negativo ela serve, cobertura baixa denuncia código sem teste, mas transformada em meta ela vira exemplo de lei de Goodhart: quando a métrica vira alvo, deixa de ser boa métrica, e a equipe aprende a escrever testes que tocam a linha sem afirmar nada só para mover o número. O consenso atual trata cobertura como piso diagnóstico, não como teto a perseguir.

A geração de testes por IA

A camada mais nova, de 2022 em diante, é a geração de testes por modelos de linguagem, e ela chega dividida entre uma promessa real e uma armadilha igualmente real.

O caso mais bem documentado é o TestGen-LLM, da Meta, descrito num artigo de fevereiro de 2024. O detalhe que importa é o enquadramento: a ferramenta não escreve testes do zero, ela melhora testes existentes, e o faz embrulhando o modelo num filtro. Cada teste que o modelo propõe só sobrevive se passar por uma bateria de checagens objetivas: compila, passa de forma confiável quando rodado várias vezes (para descartar flaky), e aumenta a cobertura sobre o que já havia. O que não satisfizer as três é descartado, “eliminando os problemas devidos à alucinação do modelo”, nas palavras do artigo. Os números do exercício na Instagram e no Facebook dão a medida da taxa de aproveitamento bruta: 75% dos casos gerados compilavam, 57% passavam de forma confiável, 25% aumentavam a cobertura. A ferramenta melhorou 11,5% das classes a que foi aplicada, e 73% de suas recomendações foram aceitas por engenheiros para produção.

A lição do TestGen-LLM não é sobre o modelo, é sobre o filtro. O valor não veio da capacidade de gerar, que produz muito refugo, e sim da verificação determinística construída em volta da geração, que separa o refugo do que presta. Esse padrão, gerar em abundância e filtrar por um critério objetivo, é o que a Meta descreveu num artigo companheiro sob o nome de “engenharia de software assistida por LLM com garantias”, e é o desenho que reaparece em quase toda aplicação séria de IA a testes. A Qodo (antiga CodiumAI) liberou, em 2024, o Cover-Agent, a primeira implementação aberta da ideia do TestGen-LLM. Numa vertente diferente, a Diffblue Cover gera testes de unidade para Java por aprendizado por reforço, não por LLM, o que a torna determinística e sem alucinação ao preço de menos flexibilidade, um contraste útil sobre onde cada abordagem paga. As ferramentas de ponta a ponta com “autocura” (testRigor, mabl, Functionize, Applitools com sua IA visual) atacam outro flanco, o da manutenção de seletores: quando a interface muda e um seletor quebraria, a ferramenta reidentifica o elemento por impressões digitais múltiplas ou por comparação visual e atualiza o seletor sozinha, tornando obsoleta boa parte do trabalho manual que motivou a crítica ao Page Object Model. Convém tratar os números dessas ferramentas de autocura e da Diffblue com a cautela devida a material de marketing; a existência da capacidade é real, a eficácia anunciada é parte não verificada.

A armadilha do verde vazio

O risco que acompanha a geração por IA é o retorno, com força, do problema do oráculo. Um teste gerado que fica verde não provou nada sobre correção; provou apenas que a execução foi consistente. A distinção, afiada num ensaio da Autonoma, é que “verde é uma medida de consistência de execução, não de correção de comportamento”. E há um modo de falha específico e perigoso: quando o mesmo modelo escreve o código e o teste, o oráculo colapsa, porque qualquer coisa que o código devolva vira o valor esperado. O teste passa e o bug embarca. A cobertura sobe, a proteção não.

É tentador ler a geração automática como o fim do trabalho de escrever teste. O que ela de fato faz é mover o gargalo. A parte tediosa, preencher cobertura, manter seletor, escrever o caso óbvio, é o que a IA absorve. A parte que ela não absorve, e que fica mais crítica justamente porque o volume de testes verdes explodiu, é o julgamento: revisar o que foi gerado, projetar o oráculo, garantir que quem verifica é independente de quem é verificado. O modo de falha da equipe deixou de ser “não temos testes” e passou a ser “temos mil testes verdes que não afirmam nada”. A defesa contra isso é velha conhecida deste material, o teste de mutação, que semeia defeitos e revela sem dó a suíte que não os pega, gerada por IA ou por gente.

Testes como oráculo dos agentes

Há uma última reviravolta, e ela devolve ao teste um papel que o debate de 2014 parecia ter enfraquecido. Nos agentes de código que geram e corrigem software sozinhos, a suíte de testes vira a especificação executável que ancora e avalia a geração. O benchmark que consolidou essa lógica é o SWE-bench, de 2023: 2.294 problemas reais tirados de issues e pull requests de doze repositórios Python, em que o patch proposto pelo modelo é julgado rodando a própria suíte do repositório. O critério é duplo e mecânico:

flowchart LR
  issue["Issue do GitHub"] --> agent["Agente propõe patch"]
  agent --> suite["Suíte de testes do repositório"]
  suite --> f2p["FAIL_TO_PASS: falhava, precisa passar"]
  suite --> p2p["PASS_TO_PASS: passava, não pode quebrar"]
  f2p --> verdict{"Ambos verdes?"}
  p2p --> verdict
  verdict -->|sim| resolved["Issue resolvida"]
  verdict -->|não| rejected["Patch rejeitado"]

O conjunto FAIL_TO_PASS reúne os testes que falhavam antes e precisam passar depois, provando que o problema foi resolvido; o conjunto PASS_TO_PASS reúne os que já passavam e não podem quebrar, provando que nada de colateral foi danificado. O patch só conta como resolução se ambos ficam verdes. Os testes são o oráculo objetivo, e o quão difícil isso é fica claro no ponto de partida do artigo, em que o melhor modelo da época resolvia menos de 2% dos casos.

Aqui o TDD ressurge, não como disciplina humana e sim como função objetivo de máquina. Escrever o teste antes de o agente programar tem uma virtude nova além das antigas: impede que a IA corrija a própria prova, o antídoto direto para a armadilha do verde vazio, já que o oráculo passa a ser independente de quem escreve o código. Esse renascimento ainda é mais tendência de pesquisa do que virada medida da indústria, e convém apresentá-lo como tal. Mas a direção é coerente com tudo o que veio antes: quando a geração de código e a geração de testes ficam baratas a ponto de serem infinitas, o recurso escasso deixa de ser escrever o teste e passa a ser projetar o oráculo que o torna digno de confiança. A régua de confiança sobre custo continua a mesma; o que a era da IA encareceu, em termos relativos, foi a única parte que a máquina ainda não faz por você, decidir o que “certo” quer dizer.

Fontes

As afirmações mais voláteis desta página, as datas de ferramentas, os números dos artigos de IA e as estatísticas de flaky, vêm das fontes primárias abaixo, registradas porque são as partes que mais provavelmente mudam de um ano para o outro:

Palavras-chave

Virada 2020+: shift-left, shift-right, teste em produção, feature flags, canary release, monitoração sintética, engenharia do caos, autocura de testes Ferramentas: Selenium, WebDriver, Cypress, Playwright, Testing Library, Chaos Monkey, Gremlin, TestGen-LLM, Qodo Cover-Agent, Diffblue Cover, testRigor, mabl, Applitools IA e teste: geração por LLM, filtro determinístico, alucinação, verde vazio, problema do oráculo, testes como especificação, SWE-bench, FAIL_TO_PASS, PASS_TO_PASS Conceitos: flaky, lei de Goodhart, cobertura como alvo, Page Object Model, localizador por papel Pessoas: David Heinemeier Hansson, Kent Beck, Martin Fowler, John Micco, Jeff Listfield