Numa manhã qualquer, você pega o card: "Implementar cancelamento de pedido". Você faz tudo certo: passa o contexto para a IA, mapeia os estados do pedido, revisa com cuidado o código que voltou e os testes passam. Você não foi preguiçoso, foi um bom desenvolvedor usando uma boa ferramenta.
Três dias depois, o comercial relata: "Não estamos conseguindo cancelar um pedido que já foi enviado". E faz sentido o sistema barrar, porque no mercado pedido enviado não se cancela, e foi o que você e a IA assumiram. O que ninguém te contou é que a sua empresa tem um acordo com a transportadora que permite interceptar a entrega, então aqui pode. Essa regra não estava no card nem no prompt, vivia com o time de operação.
E aí está o problema: ninguém errou. A regra existia, mas no lugar errado, na cabeça de algumas pessoas e nunca num formato que o card, o prompt ou o código pudessem consultar. Faltou alguém transformar uma regra de negócio difusa num acordo explícito antes da primeira linha de código.
Esse é o ponto cego que a IA não fechou e que talvez tenha até alargado, porque, embora ela tenha ficado absurdamente boa em resolver o "como", que é traduzir uma intenção clara em implementação, continua dependendo de um humano para definir "o que o sistema deve fazer" e "por quê". E é exatamente aí que mora o BDD, uma prática que muita gente deu como morta na última década e que, na minha leitura, acabou de ficar mais relevante do que nunca.
BDD?
Antes de defender qualquer coisa, preciso garantir que estamos falando da mesma coisa. Se você nunca trabalhou com BDD, ele é uma prática para alinhar, em linguagem natural, como o software deve se comportar em um cenário.
Existem três coisas bem diferentes que costumam ser tratadas como uma só debaixo do nome "BDD", e essa confusão é responsável por boa parte da má fama da prática. Vamos separá-las.
BDD (Behavior-Driven Development), formulado por Dan North por volta de 2006 como uma evolução do TDD, nunca foi sobre técnica e sim sobre conversa. A ideia central era atacar o problema mais caro do desenvolvimento de software (que nunca foi escrever código): escrever o código errado com perfeição técnica, porque dev, QA e negócio entenderam a mesma frase de três formas diferentes. BDD propôs que essas três pessoas sentassem juntas e descrevessem o comportamento esperado do sistema em exemplos concretos, numa linguagem que todas entendessem.
Gherkin é só a notação que saiu dessa conversa, aquele formato Dado / Quando / Então (Given / When / Then) que estrutura um exemplo de comportamento em linguagem quase natural.
Cucumber (e seus primos, SpecFlow/Reqnroll no .NET, Behave no Python, JBehave no Java, Godog no Go) é a ferramenta que pega o texto Gherkin e amarra cada linha a um pedaço de código de teste, transformando a especificação em algo executável.
Quase toda crítica ao "BDD" na verdade é uma crítica ao Cucumber mal usado, e confundir os três é o que fez muita gente jogar a água fora com o bebê dentro.
Guarde essas definições porque elas são a chave do argumento. Quando a discussão vira "IA já escreve os testes, então para que BDD?", quem fala isso está olhando só para o Cucumber, que é a camada mais barata e mais automatizável das três e o valor do BDD nunca esteve aí.
Por que o BDD "morreu"?
O BDD ganhou uma fama ruim, mas confesso que era merecida em boa parte. Eu já vi, e provavelmente você também, o cemitério clássico.
Times que adotaram Cucumber porque era moderno, escreveram trezentos cenários Gherkin que ninguém de negócio nunca leu, e transformaram cada .feature em um teste de integração disfarçado, só que mais verboso e mais frágil.
O Given virava um setup de banco gigante, o When chamava direto um método interno, e o Then fazia assert em campo de DTO, de modo que ninguém do produto chegava perto daquilo, porque era teste automatizado (com um custo de cerimônia) que não pagava nenhum benefício.
Quando o BDD é só isso, ele realmente não vale a pena, e a IA escrever esses testes por você só torna o desperdício mais rápido.
Gherkin que só o desenvolvedor lê não é BDD, e sim um framework de teste de aceitação com sintaxe esquisita. Se a pessoa de negócio ou de suporte nunca lê o Gherkin, você pagou o preço do BDD sem comprar o produto.
Mas na verdade, o diagnóstico de que "o BDD morreu" era parcial, porque ele matou o BDD como tecnologia, aquele que vira framework de teste, mas não tocou no BDD como alinhamento, já que o problema de três pessoas entenderem a mesma regra de três jeitos nunca foi resolvido por ferramenta nenhuma, apenas adiado. E a IA, ao acelerar brutalmente a produção de código, trouxe esse problema adiado de volta para a mesa, agora com urgência.
E aqui vale notar uma ironia que muda a conta. O que matou o BDD da primeira vez foi o custo de manter as step definitions, o código que amarra cada linha do Gherkin ao sistema, e que alguém precisava escrever e atualizar à mão. Só que esse é exatamente o tipo de código mecânico e repetitivo que a IA faz bem e barato. Ou seja, a mesma IA que devolveu urgência ao problema que o BDD resolve também derrubou o custo da parte que fez o BDD fracassar e é por isso que "já tentamos isso e não deu certo" não serve mais como argumento.
O que a IA automatizou e o que ela escancarou
Vou tentar ser "pé no chão" aqui. A IA generativa e agêntica é excelente em pegar uma intenção bem especificada e produzir a implementação, de forma que se você der a ela um comportamento claro, ela escreve o controller, o service, o repositório e o teste. A camada "como o código faz isso" desabou de preço.
Só que ela é tão boa nisso que criou um novo risco, o de produzir a coisa errada com altíssima velocidade e qualidade técnica, já que a IA preenche lacunas: você pede "cancelar pedido" e ela inventa uma regra plausível para o caso de pedido já enviado, porque tem que escrever alguma coisa ali.
A regra inventada parece razoável, passa no teste que a própria IA escreveu, afinal o teste valida a regra que ela inventou e não a que o negócio queria, e, aqui está o ponto, sobrevive até à sua revisão, porque, para reprovar a regra inventada, você precisaria conhecer a verdadeira, e ela não estava escrita em lugar nenhum. Revisão de código só pega o que o revisor conhece, e o que ninguém documentou, ninguém revisa.
Esse é o ponto que quero martelar: a IA não tem o contexto de negócio, ela tem o contexto da internet. E ela não inventa do nada: o contexto da internet diz que pedido já enviado não cancela direto, porque abre uma logística reversa, que gera uma devolução, que dispara uma nota fiscal de entrada e precisa de aprovação fiscal. Essa é a regra mais comum do mercado, e é exatamente por isso que a IA a assume com tanta confiança.
Só que na sua empresa a regra é o oposto, porque pedido enviado pode, sim, ser cancelado, já que a transportadora recebe uma notificação e simplesmente não entrega. Essa regra, a sua, não está em nenhum dataset de treino, está na cabeça da Maria da operação, e o trabalho de extrair isso da cabeça dela e transformar em algo executável é, palavra por palavra, a definição original de BDD.
A IA derrubou o custo de escrever código e, com isso, elevou o custo relativo de especificar o código certo. Onde antes a especificação ruim só atrasava, agora ela se materializa em produção em minutos, porque o gargalo se mudou da implementação para a intenção.
Gherkin como contrato que disciplina o código gerado
Aqui o Gherkin reaparece, e não por nostalgia. Repare na coincidência: a gente passou vinte anos lapidando um formato para alinhar humanos com humanos, e ele acabou sendo quase perfeito como entrada para uma IA.
Pense no que um bom cenário Gherkin é: uma descrição de comportamento, estruturada, em linguagem natural, com exemplos concretos e condições de borda explícitas. É exatamente o tipo de prompt que faz uma IA gerar bom código, e ao mesmo tempo, o exato artefato que permite verificar o que ela gerou.
Veja a diferença entre alimentar a IA com um prompt solto e alimentá-la com um cenário acordado:
# A regra que saiu da conversa entre tech lead, QA e o pessoal de negócio
Funcionalidade: Cancelamento de pedido
Cenário: Pedido pago e ainda não enviado é cancelado direto
Dado um pedido no estado "PAGO"
E que ainda não foi despachado
Quando o cliente solicita o cancelamento
Então o pedido deve ir para o estado "CANCELADO"
E o estorno do pagamento deve ser iniciado
Cenário: Pedido já enviado é cancelado notificando a transportadora
Dado um pedido no estado "ENVIADO"
Quando o cliente solicita o cancelamento
Então o pedido deve ir para o estado "CANCELADO"
E o estorno do pagamento deve ser iniciado
E a transportadora deve ser notificada para não entregar
Primeiro, este Gherkin é um prompt muito melhor do que "crie um endpoint que cancela pedido", porque carrega a regra de negócio que a IA jamais adivinharia.
Segundo, ele é um critério de verificação independente, porque quando a IA gera a implementação, esses cenários automatizados via Cucumber dizem objetivamente se o código fez o que o negócio acordou e não o que a IA imaginou.
A ordem inverte: o humano define o comportamento em Gherkin, a IA implementa e o cenário verifica. O teste deixa de ser derivado do código e vira o contrato que veio antes dele.
Quando a IA escreve o código e o teste do código, ela está marcando a própria prova. O cenário de BDD, definido antes e pela pessoa que entende o domínio, é a única nota que ela não consegue fraudar.
E note que isso não é um exercício de cerimônia, porque o Given/When/Then aqui não é firula, e sim a estrutura mínima para que a regra fique sem ambiguidade tanto para o humano quanto para a máquina.
Gherkin como documentação viva para o suporte
Tem um terceiro uso do Gherkin que, na minha experiência, sozinho já justifica a prática, e que ficou ainda mais valioso agora que o código nasce rápido e some na velocidade dos commits. O cenário Gherkin é a melhor documentação de regra de negócio que existe, porque é a única que não pode mentir sobre o que afirma.
Um cenário Gherkin automatizado é diferente de uma página de documentação mantida manualmente à parte, porque se a regra muda no código e o cenário não é atualizado, o build quebra. Como a documentação e o comportamento estão amarrados pelo CI, não dá para a documentação ficar desatualizada sem alguém ser obrigado a encarar isso, já que a esteira não deixa passar.
Imagine o atendente do suporte recebendo um chamado: "cliente quer cancelar um pedido que já foi enviado, isso é possível?". Em vez de abrir o código, ou pior, perguntar no Teams "alguém sabe a regra de cancelamento?", ele abre a página de features Gherkin e lê:
Cenário: Pedido já enviado é cancelado notificando a transportadora
Dado um pedido no estado "ENVIADO"
Quando o cliente solicita o cancelamento
Então o pedido deve ir para o estado "CANCELADO"
E o estorno do pagamento deve ser iniciado
E a transportadora deve ser notificada para não entregar
Está tudo lá, em português, sem palavrão técnico e com a garantia de que essa é a regra que de fato roda em produção, porque, se não fosse, o build estaria vermelho.
O suporte para de adivinhar, o comercial consegue entender o comportamento sem ler C#, e o dev novo, no onboarding, lê as features como se fossem o manual do domínio, que é exatamente o que elas são.
Documentação que não está amarrada à execução é ficção bem-intencionada. O valor único do Gherkin automatizado é que tudo o que ele afirma o sistema é obrigado a manter verdadeiro, sob pena de não buildar.
Esse benefício sempre existiu, mas ficou mais precioso na era da IA por um motivo específico, porque, quando o código é gerado e regenerado rápido, a memória institucional sobre "por que isso funciona assim" se perde mais fácil ainda. O cenário Gherkin é o que sobrevive à rotatividade do código.
Como isso se parece na prática (e onde a IA entra no fluxo)
Tudo até aqui foi conceito. Mas na prática? O fluxo que faz sentido para mim num time que usa IA pesado no dia a dia:
A conversa continua sendo humana, porque dev, QA e negócio, os "três amigos" do BDD clássico, discutem o comportamento e os casos de borda, e isso a IA não faz por você, já que ela não tem acesso à Maria da operação.
O que a IA pode fazer aqui é ajudar a rascunhar cenários a partir de uma descrição e, principalmente, provocar: "e se o pedido tiver dois itens e só um deles já foi despachado? e se estiver em separação no estoque, conta como enviado ou não?". Ela é ótima como geradora de casos de borda para você aceitar ou rejeitar, mas péssima como autora final da regra.
O Gherkin acordado vira o prompt estruturado, e quando você entrega os cenários para a IA gerar a implementação, o código sai mais certo de primeira porque a intenção estava clara.
Os cenários automatizados via Cucumber viram o portão de qualidade, de forma que o código gerado só passa se satisfizer o comportamento que o humano definiu, e a IA não marca a própria prova.
E os mesmos arquivos .feature ficam no repositório como documentação viva, lidos por suporte, produto e devs novos.
Repare que em nenhuma etapa a IA foi descartada, já que ela acelera a conversa, escreve o grosso do código e até sugere bordas. O que ela não faz é substituir a definição humana do que é certo, e o BDD é justamente o método de capturar essa definição num formato que serve à máquina e à pessoa ao mesmo tempo.
Um exemplo para concretizar a ideia
Imagine um produto que cobra por mensagem enviada, e a tarifa depende de uma janela de tempo, de modo que a mensagem enviada até 24h depois da última resposta do usuário entra numa tarifa, e se passar disso entra em outra, mais cara. É regra de negócio pura, dessas que não têm nada a ver com código e tudo a ver com o contrato da operadora.
Um dev experiente refatora esse trecho com bastante ajuda de IA. O código sai limpo, bem testado, passa em tudo e sobe, mas começa a divergir centavo a centavo na fatura, daquele jeito que ninguém percebe no dia e só nota no fechamento do mês, quando o financeiro pergunta por que o número não bate.
O problema não está no código, que faz exatamente o que foi escrito. É que a janela tinha uma exceção. Digamos que mensagem que responde a um template não conta o tempo do mesmo jeito, que ninguém falou para a IA, e ela, coerente como sempre, preencheu a lacuna com a interpretação mais óbvia, errada para aquele contrato específico. O teste passava porque validava a regra que a IA inventou, que era a prova marcada pelo próprio aluno.
Agora imagine o mesmo caso com BDD na frente. Se aquela regra tivesse virado cenário antes do código, com a janela, a exceção do template e a tarifa de cada caso, a IA teria a regra certa na entrada e o cenário teria reprovado a interpretação errada na saída. O centavo divergente nunca chegaria à fatura, e quando o cliente questionasse a cobrança, o suporte abriria a pasta de features e leria a regra em português, sabendo que é a que roda em produção, porque senão o build não teria deixado subir.
Conceitos bons, contexto errado. A IA não errou o código, ela acertou o código de uma regra que ninguém tinha escrito. Foi a falta do contrato em linguagem natural, não a IA, que custou o fechamento do mês.
Antes de sair escrevendo Gherkin
Esse artigo é sobre por que o BDD voltou a importar, e não um tutorial de como escrever cenários, mas aqui vai o aviso mais importante para quem se animou: a maneira como você escreve o Gherkin decide se ele vai te entregar tudo que prometi acima ou virar mais um teste de integração disfarçado que ninguém de negócio lê.
O erro 1 é escrever Gherkins imperativos, descrevendo a mecânica da tela, com "clico no botão X", "preencho o campo Y", "navego para a página Z". Isso é frágil, porque quebra quando a UI muda, é ilegível para quem não é dev, e perde justamente o valor de documentação:
# Imperativo: amarrado à tela, quebra quando a UI muda, e o negócio não lê
Cenário: Cancelar pedido enviado
Dado que estou logado como atendente
E que abri a tela de detalhes do pedido 1234
Quando clico no botão "Cancelar" do menu lateral
E confirmo no modal clicando em "Sim, cancelar"
Então devo ver o texto "Pedido cancelado" no topo da página
O caminho é o Gherkin declarativo, que descreve o comportamento e a regra de negócio, e não o passo a passo da interface:
# Declarativo: descreve a regra, sobrevive a qualquer mudança de tela
Cenário: Pedido já enviado é cancelado notificando a transportadora
Dado um pedido no estado "ENVIADO"
Quando o cliente solicita o cancelamento
Então o pedido deve ir para o estado "CANCELADO"
E a transportadora deve ser notificada para não entregar
O primeiro fala de botões, modais e textos na tela, enquanto o segundo fala da regra de negócio, sendo a mesma frase que a Maria da operação e o atendente de suporte conseguem ler e confirmar.
A pergunta guia, que vale colar na parede do time, é simples: "se a implementação mudar, essa frase precisa mudar?". Se precisar, então você escreveu mecânica e não comportamento, e o melhor é reescrever pensando em quem vai ler, que é a pessoa de negócio que precisa confirmar a regra e o atendente de suporte que vai consultar o cenário para responder o cliente. Se esses dois não entendem a frase, ela está técnica demais.
Para se aprofundar de verdade, deixo dois pontos de partida que valem mais que dez posts genéricos, que são o texto original do Dan North, Introducing BDD, onde a prática nasce justamente como uma conversa sobre comportamento, e o guia Writing better Gherkin da própria Cucumber, que detalha o estilo declarativo e como manter cenários curtos e centrados no negócio.
Gherkin bem escrito é em linguagem de negócio e suporte, não de UI nem de código. A regra é dizer o que o sistema faz, nunca como ele faz na tela. Se o seu cenário quebra quando você troca um botão de lugar, ele não é documentação de comportamento, e sim teste de interface fantasiado.
O trabalho que sobrou para você
A pergunta de abertura, "a IA escreve código, então para que BDD?", carrega um erro de mira, porque compara a IA com a camada errada do BDD, a do Cucumber, que sempre foi a mais barata e a mais descartável.
O coração do BDD nunca foi automatizar teste, e sim alinhar humanos sobre o que o sistema deve fazer e registrar esse acordo num formato que não pode mentir. A IA não tocou nesse coração, apenas tornou mais barato tudo ao redor dele, e com isso deixou o coração mais exposto do que nunca, porque, agora que escrever código não é mais o gargalo, especificar o código certo virou o trabalho que sobra, justamente o trabalho que a IA não faz por você.
Gherkin, esse formato velho de quase vinte anos, virou três coisas de uma vez na era da IA, que são o prompt que faz a IA gerar o código certo, o contrato que verifica se ela gerou mesmo, e a documentação viva que o suporte lê sabendo que é verdade. Não foi descartado, foi promovido.
E se essa ideia de "a especificação é a fonte de verdade, o código é gerado contra ela" soou maior do que um cenário de cancelamento de pedido, é porque ela é mesmo. Levado ao extremo, esse princípio é o que o mercado passou a chamar de Spec-Driven Development (SDD), onde não só o comportamento, mas também arquitetura, bordas e restrições viram especificação versionada que o agente de IA consome para gerar código, teste e documentação. O BDD é a porta de entrada natural para esse mundo, mas como aplicar SDD numa aplicação de verdade é assunto que merece um artigo só dele, que pretendo escrever em breve.
Se você esquecer tudo desse artigo menos uma coisa, lembre disso: a IA tirou de você o trabalho de escrever o código, mas não tirou, e não vai tirar, o trabalho de decidir qual código é o certo. BDD sempre foi sobre esse segundo trabalho, e ele acabou de ficar o mais valioso dos dois.
Gostou do artigo? Comente abaixo sobre o que ele te fez pensar e que práticas você deseja aplicar. Além disso, comente sobre o que faltou no artigo que é informação importante sobre o assunto.
Top comments (1)
Opa, mais um, esse eu vi antes de ir o link pro linkedin.
Tenho gostado de acompanhar os artigos!
E apesar de conhecer BDD, assim como outros conceitos nos artigos passados, os exemplos práticos, detalhes e argumentações agregam muito.