Questão de Engenharia de Software — TDD e BDD (Test-Driven Development e Behavior Driven Development) — CESPE / CEBRASPE 2026

BDD (Behavior Driven Development) e sua relação com o TDD

Gabarito: Certo (C). O BDD é, de fato, uma evolução do TDD que amplia o foco dos testes para o comportamento do sistema, priorizando a colaboração entre desenvolvedores e stakeholders por meio de especificações executáveis escritas em linguagem ubíqua, geralmente no formato Gherkin. Essa é a definição consagrada na literatura de engenharia de software, e o enunciado a reproduz com precisão.

O Desenvolvimento Orientado a Comportamento (BDD) surge como uma resposta às limitações do Desenvolvimento Orientado a Testes (TDD). Enquanto o TDD se concentra em escrever testes unitários antes do código, o BDD propõe uma abordagem mais ampla: em vez de focar apenas na implementação, ele busca alinhar o desenvolvimento aos comportamentos esperados do sistema, do ponto de vista do negócio. Essa mudança de perspectiva é fundamental para entender a questão.

A essência do BDD está na colaboração. Ele promove a comunicação entre desenvolvedores, testadores e stakeholders (como product owners, analistas de negócio e clientes) para definir, de forma conjunta, o que o sistema deve fazer. Essa definição é materializada em especificações executáveis, que são escritas em uma linguagem ubíqua — ou seja, uma linguagem comum, compreensível tanto para o lado técnico quanto para o lado de negócio. O formato mais conhecido para essas especificações é o Gherkin, que utiliza palavras-chave como Dado, Quando e Então para descrever cenários de comportamento.

Na prática, o BDD funciona assim: a equipe se reúne para discutir uma funcionalidade, e dessa discussão surgem cenários escritos em Gherkin. Esses cenários são, ao mesmo tempo, documentação viva e critérios de aceitação. Eles podem ser automatizados com ferramentas como Cucumber, SpecFlow ou Behave, que interpretam o Gherkin e executam os passos definidos. Dessa forma, as especificações se tornam testes automatizados que validam o comportamento do sistema, garantindo que ele atenda às expectativas do negócio.

A distinção crucial entre TDD e BDD é o foco: o TDD é uma técnica de programação que se concentra em testes unitários e na qualidade do código, enquanto o BDD é uma metodologia de colaboração que se concentra no comportamento do sistema e na comunicação entre as partes interessadas. O BDD não substitui o TDD; ele o estende, adicionando uma camada de especificação de negócio que orienta o desenvolvimento. É exatamente essa relação de extensão que o enunciado descreve.

A pegadinha que a banca poderia explorar aqui seria inverter os papéis, afirmando que o TDD estende o BDD, ou que o BDD foca apenas em testes unitários. No entanto, o enunciado está correto ao afirmar que o BDD estende o TDD, focando na colaboração e na comunicação, e que as especificações são escritas em linguagem ubíqua no formato Gherkin. Não há nenhum termo trocado ou conceito invertido.

Alternativa C — ✅ CERTO ⟵ GABARITO

A afirmativa está correta porque descreve com precisão o BDD. Ele é, de fato, uma extensão do TDD, pois incorpora a ideia de escrever testes antes do código, mas amplia o escopo para incluir a colaboração entre desenvolvedores e stakeholders. As especificações executáveis, escritas em linguagem ubíqua (Gherkin), são a forma de materializar essa colaboração, transformando o comportamento esperado em critérios de aceitação automatizáveis. O enunciado captura todos os elementos essenciais do BDD: a extensão do TDD, o foco na colaboração e comunicação, e o uso de especificações executáveis em Gherkin.

Gabarito: letra C (Certo).