Questão de Engenharia de Software — Conceitos Básicos em Engenharia de Software — FCC 2017
Engenharia de Software›Conceitos Básicos em Engenharia de Software
Código
fc040560
Banca
FCC
Órgão
TST
Ano
2017
Nível
Médio
Cargo
Técnico Judiciário – Programação
Considere o cenário abaixo.Característica: Usuário negocia ações.Cenário: o usuário solicita uma venda antes do fechamento da negociação.[Given] que eu tenho 100 ações do estoque da empresa A.And eu tenho 150 ações do estoque da empresa B.And o momento é antes do fechamento da negociação.[When] eu peço para vender 20 ações da empresa A.[Then] eu devo ficar com 80 ações do estoque da empresa A.And eu devo ficar com 150 ações do estoque da empresa B.And uma ordem de venda de 20 ações da empresa A deve ser executada.Este cenário utiliza a abordagem Given-When-Then originada e usada no método
ATest-Driven Development − TDD.
BExtreme Programming − XP.
CBehavior-Driven Development − BDD.
DFeature-Driven Development − FDD.
ERapid Application Development − RAD.
Revelar gabarito e comentário▾
GabaritoC — Behavior-Driven Development − BDD.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Behavior-Driven Development (BDD)
Gabarito: letra C. O cenário apresentado utiliza a estrutura Given-When-Then, que é a base do Behavior-Driven Development (BDD). Nessa abordagem, os cenários descrevem o comportamento esperado do sistema em uma linguagem ubíqua, facilitando a comunicação entre desenvolvedores, testadores e stakeholders. As alternativas listam outros métodos ágeis e de desenvolvimento, mas apenas o BDD adota o formato Given-When-Then como peça central.
Análise das alternativas
Métodos ágeis: BDD (Behavior-Driven Development) (Given-When-Then (marca registrada), Foco no comportamento do sistema, Linguagem ubíqua); TDD (Test-Driven Development) (Ciclo Red-Green-Refactor, Testes unitários); XP (Extreme Programming) (Programação em par, Integração contínua); FDD (Feature-Driven Development) (Funcionalidades, Modelagem e entregas curtas); RAD (Rapid Application Development) (Prototipação rápida, Iterativo)
Alternativa A — ❌ Incorreta
Test-Driven Development (TDD) utiliza o ciclo Red-Green-Refactor, com foco em testes unitários escritos antes do código. O formato Given-When-Then não é inerente ao TDD, embora possa ser usado em alguns frameworks, mas sua origem e uso predominante é no BDD.
Alternativa B — ❌ Incorreta
Extreme Programming (XP) é um método ágil que enfatiza práticas como programação em par, integração contínua e desenvolvimento orientado a testes (TDD). O XP não define o formato Given-When-Then como parte de seu arcabouço; ele é mais genérico.
Alternativa C — ✅ Correta ⟵ GABARITO
Behavior-Driven Development (BDD) foi proposto por Dan North como uma evolução do TDD, focando no comportamento do sistema. A estrutura Given-When-Then é sua marca registrada: Given (contexto), When (ação) e Then (resultado esperado). Exatamente o que a questão apresenta.
Alternativa D — ❌ Incorreta
Feature-Driven Development (FDD) é um método ágil voltado para o desenvolvimento de funcionalidades, com ênfase em modelagem e entregas curtas. Não utiliza o formato Given-When-Then.
Alternativa E — ❌ Incorreta
Rapid Application Development (RAD) é um modelo de desenvolvimento iterativo com prototipação rápida, sem uma notação específica como Given-When-Then.
NÃO CAIA NESSA!
A banca lista vários métodos ágeis que são próximos (XP, TDD, FDD, RAD) para confundir o candidato. A chave é lembrar que o Given-When-Then é uma invenção do BDD. Muitos confundem com TDD por envolver testes, mas o BDD foca no comportamento visível, não em testes unitários.