# O gargalo não é o código, é o teste · Diário da fábrica URL: https://www.edugalbs.com/fabrica-24x7/capitulos/o-gargalo-e-o-teste > Somando o tempo das etapas, testar levou mais do que desenvolver. A próxima grande economia está no teste. Capítulo 04 · 20 de outubro de 2026 ## O gargalo não é o código, é o teste Somando o tempo das etapas, testar levou mais do que desenvolver. A próxima grande economia está no teste. ⏱️ 10 min de leitura **TL;DR** O capítulo fala de por que testar ficou mais caro do que programar com IA: o custo estava nos turnos, não só no contexto, e a pirâmide de testes virou de cabeça para baixo. A saída foi o motor executar e o agente escrever o teste uma vez, antes do código. Resolvido o teste, o gargalo andou de novo. No capítulo anterior, a fábrica passou a primeira noite inteira trabalhando sem mim. Acordei com 10 tarefas entregues, testadas e integradas. Mas, quando somei o tempo das etapas daquela noite, uma conta não fechava. Testar levou mais do que desenvolver: cerca de 3h15 contra 2h10. E 1h20 desse teste foi um agente esperando um comando terminar. A pista já estava no capítulo 1, [**Escala 6x1? Aqui é 24x7**](https://www.edugalbs.com/fabrica-24x7/capitulos/escala-24x7): a segunda execução real levou quase 40 minutos, com a integração contínua rodando quatro vezes até passar. Na hora, eu achei que era coisa de começo. Era o padrão. Este capítulo é sobre essa conta: por que escrever código deixou de ser a parte cara do trabalho, e o que eu mudei para as noites seguintes não gastarem o relógio esperando. ![A primeira noite, tempo somado das etapas: desenvolver levou 2h10; testar levou 3h15, das quais 1h20 foram um agente esperando um comando terminar](https://www.edugalbs.com/fabrica-24x7/media/capitulo-04-teste.png) ### Onde o tempo ia Quando olhei para dentro das execuções, a surpresa não foi o teste demorar. Foi onde o tempo ia. Antes, uma legenda para o resto do capítulo: - ⚙️ **Motor**: o orquestrador da fábrica que apresentei no capítulo 1. Um programa comum, determinístico, sem IA, que faz sempre a mesma coisa do mesmo jeito. - 🤖 **Agente**: uma IA fazendo o trabalho. Rodar um teste é barato. Um comando roda a suíte, ela passa ou falha, e acabou. O caro era tudo o que acontecia em volta, quando quem testa é uma IA: - 🤖 **Ler**: o agente de testes lia registros de execução inteiros, alguns com centenas de kilobytes, para descobrir o que tinha falhado. - 🤖 **Esperar**: ele disparava um comando longo e ficava consultando se tinha terminado, dentro do próprio turno, com condições de espera que às vezes nunca se cumpriam. - 🤖 **Reler**: a cada turno, ele relia o contexto inteiro da tarefa. ### Não é só o contexto, é o turno Eu jurava que a segunda noite tinha ficado mais lenta porque cinco execuções disputavam o processador. Quando a IA cruzou os números, deu outra coisa: a suíte levava até um pouco menos que na primeira noite. O que tinha crescido era o número de turnos do agente de testes, que passou de 400 em uma só execução. Quando se fala em economizar com IA, quase todo mundo pensa no contexto: o quanto de texto entra na conversa. Só que o modelo relê o contexto inteiro a cada turno. Toda vez que o agente roda um comando, lê um arquivo ou confere um resultado, é mais uma leitura de tudo. Uma conta simples mostra o tamanho disso: - **500 mil tokens de contexto, 5 turnos**: o modelo lê cerca de 2,5 milhões de tokens na sessão. - **250 mil tokens de contexto, 20 turnos**: metade do contexto, e cerca de 5 milhões de tokens lidos. O dobro. ![Duas sessões: uma com 500 mil tokens de contexto e 5 turnos lê 2,5 milhões de tokens; outra com 250 mil e 20 turnos lê 5 milhões. Na fábrica, o agente de testes de uma única execução fez mais de 200 chamadas de ferramenta, com contexto médio perto de 240 mil tokens, e releu cerca de 37 milhões de tokens](https://www.edugalbs.com/fabrica-24x7/media/capitulo-04-turnos.png) Na fábrica, os números eram bem maiores. Em uma execução de 2 de outubro, o agente de testes fez mais de 200 chamadas de ferramenta, com um contexto médio perto de 240 mil tokens. No fim, ele tinha relido cerca de 37 milhões de tokens, e essa releitura respondeu por cerca de três quartos do que ele custou. Os provedores guardam por alguns minutos o que acabou de ser lido, e reler esse trecho custa uma fração de um token novo. Mas um agente que fica esperando um comando longo pode voltar com essa memória expirada e pagar a leitura inteira de novo. > **Cuidar do que entra no contexto ajuda. Cuidar de quantas vezes ele é relido ajuda tanto quanto.** ### A pirâmide de cabeça para baixo Quem trabalha com software conhece a pirâmide de testes. Na base, muitos testes unitários, pequenos, rápidos e baratos. No topo, poucos testes de ponta a ponta, que abrem o aplicativo e simulam um usuário, lentos e caros. ![Três pirâmides coloridas por quem faz o trabalho: verde para o motor, sem IA, e laranja para o agente. Na clássica, tudo roda sem IA e a base de testes unitários é rápida e barata. Com agentes e sem cuidado, tudo passa pelo agente, a pirâmide se inverte e o unitário fica com 64% do custo. Na que funcionou, a base é a execução pelo motor, em verde, e o meio e o topo são do agente: os testes escritos uma vez, antes do código, e o julgamento](https://www.edugalbs.com/fabrica-24x7/media/capitulo-04-piramide.png) A pirâmide sempre foi ordenada pelo custo de executar o teste. Com agentes, o que manda é outro custo: o de escrever o teste, esperar por ele e interpretar o resultado, pago em tokens. E esse custo pesa mais justamente na base, que é onde ficam mais testes. Os números confirmaram. O teste respondia por quase metade do custo de uma execução. Quando eu acrescentei os testes de comportamento, que descrevem o que o usuário faz na tela, passou de 60%. Em uma execução, o agente de testes sozinho ficou com cerca de dois terços do custo. Também tentei o outro extremo e desliguei os testes em uma execução. Ela saiu barata e rápida, e deixou passar três regressões, coisas que funcionavam e pararam de funcionar. ### O motor executa, o agente escreve uma vez A resposta foi separar dois trabalhos que estavam misturados e gastar IA só onde existe uma decisão a tomar. O agente escreve o teste uma vez, e o motor roda sempre. Tudo o que era execução saiu da mão do agente: - ⚙️ **Rodar a suíte**: quem roda é o motor, e ele devolve ao agente só o resumo das falhas. - ⚙️ **Escolher os testes**: os testes afetados por uma mudança saem do mapa de quem usa o quê no código, não de um palpite do agente. - ⚙️ **Falhas antigas**: uma lista das falhas que já existiam na main, para a execução não levar a culpa por um erro que não é dela. Havia nove falhas assim sendo contadas na conta errada. - ⚙️ **Esperas**: tempo limite, nova tentativa e espera ficam com o motor, fora do turno do agente. - ⚙️ **Ambiente fixo**: a mesma suíte levava 29 minutos dentro do aplicativo e 6 a 7 no terminal, por causa de uma configuração herdada sem querer. Corrigido isso, ela caiu para cerca de 5 minutos. - ⚙️ **Teste pesado na versão**: a suíte inteira, a regressão e os testes de ponta a ponta saíram de cada tarefa e foram para o fechamento de uma versão, em um corte que eu marco no roadmap. O agente ficou com o que pede julgamento: - 🤖 **Decidir o que testar**: a partir do critério de aceite. - 🤖 **Escrever o teste novo**: uma vez, antes do código. - 🤖 **Entender uma falha**: já resumida pelo motor. ### A terceira noite: o custo despencou, o relógio não A primeira noite com a ferramenta atualizada mostrou os dois lados da mudança. O custo do teste por execução caiu para uma fração do que era, algo entre um quinto e um vigésimo. Em tokens, o problema estava resolvido. No relógio, não. A suíte, agora rodada pelo motor, passou a levar cerca de 30 minutos por rodada, contra 4 a 11 antes. Foram quatro rodadas naquela noite, e três estouraram o tempo limite. Uma delas levou a execução até um ponto do fluxo em que só eu decido, e ela ficou parada esperando eu acordar. A automação não atravessou a minha aprovação, como deve ser. Mas aquela execução parou até de manhã. Levar o teste pesado para o fechamento de uma versão era, na prática, reconstruir a integração contínua de outro jeito. Na época, escrevi: > "Comecei com o gargalo no CI e voltei com o gargalo no CI. É engraçado como o gargalo faz um loop." ### Testes antes do código Faltava uma pergunta: quem escreve o teste? Desde o começo, a regra era que o agente que desenvolve nunca escreve os próprios testes, para não testar o próprio viés. Só que o agente de testes vinha depois do desenvolvimento e lia o código pronto. Pagava a conta de reler tudo e, mesmo assim, escrevia os testes a partir do que o código fazia, e não do que a tarefa pedia. Então inverti a ordem em um fluxo novo de desenvolvimento. Com o exemplo do aplicativo de tarefas (To Do) do capítulo 2, o pedido "quero adicionar uma data prevista nas tarefas" passa a andar assim: - 🤖 **Teste primeiro**: o agente de testes lê a tarefa e os critérios de aceite, não o código. Cada critério ganha pelo menos um teste: a tarefa grava a data prevista, o card mostra a data, uma tarefa sem data continua funcionando. Ele olha só as partes públicas que os critérios citam, como a tela do card e a função que grava a tarefa, e nunca o miolo que a mudança vai reescrever. Os testes vão para a cópia isolada antes de qualquer linha de código, e uma trava impede o desenvolvedor de editá-los. - 🤖 **O que não dá para testar fica escrito**: um critério que não dá para verificar automaticamente, como um detalhe visual ou uma medida, vai para uma lista própria, com o motivo. Nada de teste de mentira para cobrir o critério. - ⚙️ **Prova de que falha**: antes de qualquer código, o motor roda só os testes novos, uma vez. Eles têm que falhar porque a data prevista ainda não existe, e não por um erro de digitação no próprio teste. Um teste que já passa volta marcado para o desenvolvedor: ou ele protege algo que já funcionava, ou está errado. Um arquivo de teste que nem roda volta para quem o escreveu. - 🤖 **Desenvolver até passar**: o desenvolvedor implementa até os testes passarem. Junto com os testes, ele recebe a lista dos testes que já existem e cobrem os arquivos que vai mexer, tirada do mapa do código. Quando quer rodar os testes, ele pede, e quem roda é o motor, que devolve só o que falhou. - 🤖⚙️ **Na tela também**: nos testes de ponta a ponta, até três cenários por tarefa são escritos primeiro, no formato dado, quando, então: "dada uma tarefa com data prevista, quando eu abro a lista, então vejo a data no card". O agente escreve os cenários, o motor roda cada passo, e um agente consertador só entra quando um cenário falha. ### A quarta noite Na noite seguinte, o fluxo novo rodou de verdade: - 10 execuções de 10, todas com sucesso. - 19 tarefas entregues. - A checagem de que os testes falham pelo motivo certo passou limpa de primeira em 11 de 11. - Os testes de ponta a ponta pegaram três defeitos reais que os unitários não pegavam. Um deles: uma tela que deslizava quase 500 pixels para o lado. - O consertador acertou nos dois sentidos. Duas vezes concluiu que o defeito estava no aplicativo e não mexeu no teste. Duas vezes corrigiu o próprio teste sem mudar o que ele verificava. Uma coisa não mudou: o revisor encontrou problemas graves em 7 das 10 execuções. Os testes não substituíram a revisão, e a revisão não substituiu os testes. Teve desperdício, claro. Duas vezes o desenvolvedor esqueceu de colocar nos elementos da tela o `data-testid`, a marcação que os cenários usam para achar cada botão, campo ou card. Sem ela, o teste não encontra o elemento e falha. Uma rodada inteira da suíte foi jogada fora em cada uma. A correção é barata, e é trabalho do motor ⚙️: conferir se cada `data-testid` que os cenários pedem existe na tela antes de rodar a suíte. **💡 Insight** Uma ajuda veio de fora. Uma das bibliotecas de teste mais usadas em JavaScript já tem um modo que mostra só os testes que falharam, e ele liga sozinho quando percebe que quem está rodando é um agente de IA. A minha impressão é que muita ferramenta vai ser reescrita pensando que quem lê é uma IA, ao lado da pessoa, e não no lugar dela. ### O gargalo andou de novo Não era a primeira vez que o gargalo mudava de lugar. Ele começou na integração contínua, que rodava em um serviço externo. Depois foi para os conflitos na hora de juntar o código, para a forma como o código estava organizado, para o planejamento, para o próprio computador, que travou com quatro execuções pesadas ao mesmo tempo, e voltou para o teste. ![Um ciclo com seis etapas por onde o gargalo passou: integração contínua em um serviço externo, conflitos ao juntar o código, organização do código, planejamento das tarefas, o computador que travou com quatro execuções e o teste. A última seta, do teste de volta para a integração contínua, está em destaque: o teste pesado na versão é a integração contínua de novo](https://www.edugalbs.com/fabrica-24x7/media/capitulo-04-ciclo.png) Resolvido o teste, ele andou mais uma vez. Comparado com o fluxo anterior, o novo cortou um terço dos tokens por tarefa. O agente de testes, que ficava com quase metade dos tokens, passou a ficar com pouco mais de um décimo. Agora era o desenvolvedor que ficava com três quartos, e mais da metade das execuções voltava para ele pelo menos uma vez para corrigir alguma coisa. A próxima economia está nessas voltas: testes de aceite mais claros e checagens baratas antes da suíte valem mais do que trocar o modelo de IA. ### O próximo passo Aquela 1h20 de um agente esperando um comando terminar não era só um problema de teste. A execução mais cara do projeto inteiro não entregou nada: um agente passou o tempo perguntando, de novo e de novo, se algo tinha terminado. No próximo capítulo, capítulo 5, [**O token mais caro é o de uma IA esperando**](https://www.edugalbs.com/fabrica-24x7/capitulos/o-token-mais-caro), conto essa execução e a regra que nasceu dela: esperar é trabalho de código. [Próximo capítulo**O token mais caro é o de uma IA esperando**A execução mais cara não entregou nada: uma IA consultando um status que não mudava. Esperar é trabalho de código.](https://www.edugalbs.com/fabrica-24x7/capitulos/o-token-mais-caro) [← Todos os capítulos](https://www.edugalbs.com/fabrica-24x7) Newsletter ### Receba os próximos capítulos. Um e-mail quando sair um capítulo novo. Sem spam, e você sai quando quiser.