Julgue o item subsequente, acerca de testes de software.
No BDD, os nomes dos métodos de testes não são códigos, mas frases com significado real, a exemplo das histórias de usuários.
GabaritoC — Certo
Gabarito: Certo (C). No BDD, os testes são escritos em linguagem natural, próxima do negócio, descrevendo comportamentos esperados — não são meros nomes de métodos técnicos, mas frases com significado real, como as histórias de usuários. Essa é a essência do BDD, que o distingue do TDD tradicional.
O BDD (Behavior Driven Development, ou Desenvolvimento Guiado por Comportamento) é uma evolução do TDD (Test Driven Development). Enquanto o TDD foca em escrever testes antes do código, o BDD amplia esse conceito ao focar no comportamento do sistema do ponto de vista do usuário e do negócio. A ideia central é promover a colaboração entre desenvolvedores, testadores e stakeholders (product owners, analistas de negócio) por meio de uma linguagem ubíqua — um vocabulário comum e compreensível por todos, sem jargões técnicos.
Na prática, o BDD utiliza uma linguagem estruturada chamada Gherkin, que descreve cenários de teste em formato de frases com significado real. A estrutura típica é:
Dado (Given): um contexto inicial.
Quando (When): uma ação ou evento.
Então (Then): o resultado esperado.
Por exemplo, um cenário de teste para um sistema de login poderia ser escrito como:
Dado que sou um usuário cadastrado Quando informo minhas credenciais corretas Então devo ser redirecionado para a página inicial
Esses cenários são escritos em arquivos de especificação (.feature) e depois automatizados com ferramentas como Cucumber, SpecFlow ou Behave. Os nomes dos métodos de teste, nesse contexto, são derivados dessas frases, tornando o teste auto-documentado e alinhado aos requisitos de negócio.
A relação com as histórias de usuários é direta: ambas buscam expressar requisitos em linguagem natural, focando no valor para o usuário. Uma história de usuário segue o formato "Como um [papel], eu quero [funcionalidade], para que [benefício]". O BDD transforma essas histórias em cenários de teste executáveis, mantendo a mesma linguagem.
A pegadinha que a banca explora aqui é a confusão entre TDD e BDD. No TDD, os testes são escritos em código (geralmente com nomes de métodos técnicos, como testeSoma() ou deveRetornarTrue()), enquanto no BDD os testes são escritos em linguagem natural, descrevendo comportamentos. A questão afirma exatamente essa característica do BDD, tornando-a correta.
Guarde essa distinção: TDD = foco no código e na implementação; BDD = foco no comportamento e no negócio. É exatamente essa fronteira que separa as alternativas desta questão.
Critério | TDD | BDD |
|---|---|---|
Foco principal | Código e implementação | Comportamento e negócio |
Linguagem dos testes | Código técnico (ex.: | Linguagem natural (ex.: Gherkin) |
Estrutura típica | Ciclo Red-Green-Refactor | Dado-Quando-Então (Given-When-Then) |
Relação com histórias de usuário | Indireta (foco técnico) | Direta (cenários derivados das histórias) |
A afirmação está correta. No BDD, os nomes dos métodos de teste não são códigos técnicos, mas frases com significado real, a exemplo das histórias de usuários. Isso é uma característica fundamental do BDD, que utiliza a linguagem Gherkin para descrever cenários de teste em linguagem natural, compreensível por todos os envolvidos no projeto. Os testes são escritos como especificações de comportamento, não como meros códigos de verificação.
Para diferenciar TDD de BDD na prova, lembre-se: TDD é "Red-Green-Refactor" (escrever teste que falha, fazer passar, refatorar), enquanto BDD é "Dado-Quando-Então" (Given-When-Then). Se a questão mencionar linguagem natural, Gherkin, ou comportamento do sistema, é BDD. Se mencionar ciclo curto de testes antes do código, é TDD.
Gabarito: letra C (Certo).
Link permanente: /questoes/ce403877