Title: Engenharia de Software / BDD
Tags: Engenharia_de_Software Resumo

front: (FGV / CGM-BH – 2024) Os benefícios da introdução do Behavior-Driven Development (BDD) em uma organização são significativos, ainda que sua implementação nem sempre ocorra sem dificuldades. Com relação aos desafios da introdução do BDD, analise as afirmativas a seguir e assinale (V) para a verdadeira e (F) para a falsa.
I. O BDD requer um alto envolvimento e colaboração empresarial. As práticas de BDD são baseadas em conversas e feedback dos usuários, que impulsionam e constroem a compreensão da equipe sobre os requisitos e sobre como eles podem agregar valor ao negócio com base nesses requisitos.
II. O BDD funciona melhor com a adoção de metodologias ágeis ou iterativa. As práticas de análise de requisitos do BDD mostram que é difícil, se não impossível, definir completamente os requisitos de modo antecipado, e que estes evoluirão à medida que a equipe aprenda mais sobre o projeto.
III. Os testes, mesmo que mal escritos, não ocasionam custos de manutenção elevados. A criação de testes automatizados, especialmente para aplicações web complexas, requer baixa habilidade, e as equipes que estão começando a adotar o BDD não consideram isso um desafio significativo.
As afirmativas são, respectivamente,
a) F – V – F.
b) V – F – V.
c) V – V – F.
d) F – F – V.
response: Letra C
comment: (V) Correto. BDD requer envolvimento e colaboração empresarial; (V) Correto. BDD funciona melhor com metodologias ágeis ou iterativas, e os requisitos evoluem à medida que a equipe aprende mais sobre o projeto; (F) Errado. Testes mal escritos podem ocasionar altos custos de manutenção, e a criação de testes automatizados para aplicações web complexas requer habilidades significativas.
tldr: - BDD (Behaviour Driven Development), criado por Dan North em 2003, é uma evolução de TDD e ATDD focada em comportamento e valor de negócio, usando uma linguagem comum entre Negócio e TI.
- A ideia central é especificar o sistema por meio de exemplos reais, em linguagem natural + linguagem ubíqua, reduzindo ruídos de comunicação e alinhando todos os stakeholders.
- Fluxo típico:
- História de usuário: “Eu, como <papel>, desejo <necessidade> para <motivo>”;
- Cenários: “Dado <contexto>, quando <evento>, então <resultado>”;
- Esses cenários podem ser automatizados (SpecFlow, JBehave, RSpec, etc.) e viram testes de regressão vivos.
- Principais práticas:
- Envolver stakeholders (outside-in development);
- Usar exemplos para descrever comportamento;
- Automatizar cenários;
- Descrever comportamento usando “deve”;
- Usar mocks/stubs/fakes para isolar módulos.
- Relação com outras abordagens:
- Como TDD: testes antes do código;
- Diferente de TDD: foco no ponto de vista do usuário (caixa-preta), não do desenvolvedor (caixa-branca);
- Como ATDD: orientado a critérios automáticos de aceitação;
- Como DDD: uso de linguagem ubíqua e foco no domínio.
- Benefícios: melhor comunicação, documentação dinâmica, compartilhamento de conhecimento, visão holística do sistema e forte foco na entrega de valor ao negócio.
link: https://documentacao.online/estudos/6xfx.html
title: BDD
Other fields (not shown on cards):
back: Letra C - (V) Correto. BDD requer envolvimento e colaboração empresarial; (V) Correto. BDD funciona melhor com metodologias ágeis ou iterativas, e os requisitos evoluem à medida que a equipe aprende mais sobre o projeto; (F) Errado. Testes mal escritos podem ocasionar altos custos de manutenção, e a criação de testes automatizados para aplicações web complexas requer habilidades significativas.

front: (CESPE / CNPq – 2024) Ao se utilizar a metodologia BDD, espera-se que as entregas sejam feitas com menor quantidade de retrabalho e com cobertura de testes automatizados, a documentação passe a ser integrada ao sistema, e os projetos passem a ter estimativas dentro do prazo, com custos controlados.
response: Correto
comment: O BDD promove a colaboração entre desenvolvedores, testadores e não técnicos para definir os requisitos usando exemplos concretos, resultando em menor retrabalho e maior cobertura de testes automatizados. A documentação se torna parte integrante do sistema, pois os cenários de teste são escritos em linguagem natural. Com requisitos claros e bem definidos, os projetos tendem a ter estimativas mais precisas, prazos cumpridos e custos controlados.
tldr: - BDD (Behaviour Driven Development), criado por Dan North em 2003, é uma evolução de TDD e ATDD focada em comportamento e valor de negócio, usando uma linguagem comum entre Negócio e TI.
- A ideia central é especificar o sistema por meio de exemplos reais, em linguagem natural + linguagem ubíqua, reduzindo ruídos de comunicação e alinhando todos os stakeholders.
- Fluxo típico:
- História de usuário: “Eu, como <papel>, desejo <necessidade> para <motivo>”;
- Cenários: “Dado <contexto>, quando <evento>, então <resultado>”;
- Esses cenários podem ser automatizados (SpecFlow, JBehave, RSpec, etc.) e viram testes de regressão vivos.
- Principais práticas:
- Envolver stakeholders (outside-in development);
- Usar exemplos para descrever comportamento;
- Automatizar cenários;
- Descrever comportamento usando “deve”;
- Usar mocks/stubs/fakes para isolar módulos.
- Relação com outras abordagens:
- Como TDD: testes antes do código;
- Diferente de TDD: foco no ponto de vista do usuário (caixa-preta), não do desenvolvedor (caixa-branca);
- Como ATDD: orientado a critérios automáticos de aceitação;
- Como DDD: uso de linguagem ubíqua e foco no domínio.
- Benefícios: melhor comunicação, documentação dinâmica, compartilhamento de conhecimento, visão holística do sistema e forte foco na entrega de valor ao negócio.
link: https://documentacao.online/estudos/6xfx.html
title: BDD
Other fields (not shown on cards):
back: Correto - O BDD promove a colaboração entre desenvolvedores, testadores e não técnicos para definir os requisitos usando exemplos concretos, resultando em menor retrabalho e maior cobertura de testes automatizados. A documentação se torna parte integrante do sistema, pois os cenários de teste são escritos em linguagem natural. Com requisitos claros e bem definidos, os projetos tendem a ter estimativas mais precisas, prazos cumpridos e custos controlados.

front: (CESPE / SEFIN de Fortaleza-CE – 2023) No desenvolvimento orientado por comportamento (BDD), as palavras-chave utilizadas nos blocos que formam os cenários são given, when e then.
response: Correto
comment: No Desenvolvimento Orientado por Comportamento (BDD), os cenários são descritos usando as palavras-chave Given (Dado), When (Quando), e Then (Então). ▪ Given estabelece o contexto inicial ou pré-condições. ▪ When descreve a ação ou evento que ocorre. ▪ Then define o resultado esperado ou as consequências. Esse formato ajuda a criar uma linguagem comum entre desenvolvedores, testers e stakeholders, facilitando o entendimento dos requisitos e expectativas do sistema.
tldr: - BDD (Behaviour Driven Development), criado por Dan North em 2003, é uma evolução de TDD e ATDD focada em comportamento e valor de negócio, usando uma linguagem comum entre Negócio e TI.
- A ideia central é especificar o sistema por meio de exemplos reais, em linguagem natural + linguagem ubíqua, reduzindo ruídos de comunicação e alinhando todos os stakeholders.
- Fluxo típico:
- História de usuário: “Eu, como <papel>, desejo <necessidade> para <motivo>”;
- Cenários: “Dado <contexto>, quando <evento>, então <resultado>”;
- Esses cenários podem ser automatizados (SpecFlow, JBehave, RSpec, etc.) e viram testes de regressão vivos.
- Principais práticas:
- Envolver stakeholders (outside-in development);
- Usar exemplos para descrever comportamento;
- Automatizar cenários;
- Descrever comportamento usando “deve”;
- Usar mocks/stubs/fakes para isolar módulos.
- Relação com outras abordagens:
- Como TDD: testes antes do código;
- Diferente de TDD: foco no ponto de vista do usuário (caixa-preta), não do desenvolvedor (caixa-branca);
- Como ATDD: orientado a critérios automáticos de aceitação;
- Como DDD: uso de linguagem ubíqua e foco no domínio.
- Benefícios: melhor comunicação, documentação dinâmica, compartilhamento de conhecimento, visão holística do sistema e forte foco na entrega de valor ao negócio.
link: https://documentacao.online/estudos/6xfx.html
title: BDD
Other fields (not shown on cards):
back: Correto - No Desenvolvimento Orientado por Comportamento (BDD), os cenários são descritos usando as palavras-chave Given (Dado), When (Quando), e Then (Então). ▪ Given estabelece o contexto inicial ou pré-condições. ▪ When descreve a ação ou evento que ocorre. ▪ Then define o resultado esperado ou as consequências. Esse formato ajuda a criar uma linguagem comum entre desenvolvedores, testers e stakeholders, facilitando o entendimento dos requisitos e expectativas do sistema.