Engenharia de Software – Metodologias

Ágeis(BDD)
Prof. Washington Almeida, MSC, ISF 27002
 Behavior Driven Development - BDD
• Desenvolvimento Orientado ao Comportamento.
• Técnica de desenvolvimento de software ágil que surge
através de uma crítica de Dan North ao TDD.
• Onde ele visava otimizar o conceito de ‘verificação e
validação’ já aplicado, e tornar mais eficiente a construção de
cenários a serem testados e/ou desenvolvidos.
• Para Kent Beck, criador do TDD, os testes devem ser escritos
antes do código do software, assim irão falhar.

3
 BDD
• Logo após, os desenvolvedores irão se basear nestes cenários
falhos, irão implementar a aplicação de maneira a fazer os
testes passar, e refatorar seu código até que fique mais limpo.
“Red-Green-Refactor”.
• E está correto, porém a grande vantagem desta prática não é
gerar testes, e sim pensar no design e nas regras negócios
antes de escrever qualquer linha de código

4
 BDD
• Assim surge o BDD, como uma prática que levaria o time de
desenvolvimento a pensar no comportamento do usuário
para entender o que deve ser feito.
• E atualmente através de conceitos e ferramentas, ele já pode
ser aplicado por todos os membros do time, e não apenas
pelos desenvolvedores.

5
 BDD
• Apresenta um framework baseado em três princípios:
– A área de negócios e o time de desenvolvimento precisam se referir
a mesma parte do sistema da mesma forma;
– Toda parte do sistema precisa ter um valor identificável e verificável
para o negócio;
– Analisar, projetar e planejar tudo de cima a baixo tem retorno
decrescente;

6
 Práticas de BDD
• Envolver as partes interessadas no processo através de Outside-in
Development (Desenvolvimento de Fora para Dentro).
• Usar exemplos para descrever o comportamento de uma aplicação ou
unidades de código.
• Automatizar os exemplos para prover um feedback rápido e testes de
regressão.
• Usar deve (should em inglês) na hora de descrever o comportamento de
software para ajudar esclarecer responsabilidades e permitir que
funcionalidades do software sejam questionadas.
• Usar simuladores de teste (mocks, stubs, fakes, dummies, spies) para
auxiliar na colaboração entre módulos e códigos que ainda não foram
escritos.

7
 BDD
• BDD é guiado pelos valores de negócios; que é o benefício trazido para o
negócio no qual a aplicação está sendo produzida.
• A única maneira na qual o benefício pode ser percebido é através de
interfaces de usuário para a aplicação, comumente (mas nem sempre) a
interface gráfica de usuário.
• Da mesma maneira, cada trecho de código, começando com a interface de
usuário, pode ser considerado como sendo um cliente de outros módulos de
código no qual a interface é utilizada.
• Cada elemento de código provê algum comportamento, o qual em
colaboração com outros elementos provê o comportamento da aplicação.
• A primeira parte de código de produção que os desenvolvedores que usam
BDD implementam é a interface de usuário, pois dessa maneira os
desenvolvedores podem se beneficiar com um feedback.
8
 BDD
• Através de código, e usando princípios de design e
refatoração, desenvolvedores descobrem colaboradores para
a interface de usuário, e posteriormente para cada unidade
de código.
• Isso os ajuda a aderirem o princípio de YAGNI (You Ain't
Gonna Need It), desde que cada trecho de código de produção
é requerido pelos negócios ou por outro trecho de código já
escrito.

9
 BDD
• O foco em BDD é a linguagem e as interações usadas no
processo de desenvolvimento de software. Desenvolvedores
que se beneficiam destas técnicas escrevem os testes em sua
língua nativa em combinação com a linguagem
ubíqua (Ubiquitous Language).
• Isso permite que eles foquem em por que o código deve ser
criado, ao invés de detalhes técnicos, e ainda possibilita uma
comunicação eficiente entre as equipes de desenvolvimento e
testes.

10
 BDD x TDD
BDD - trabalha para definir como uma demanda chega ao desenvolvedor,
integrar diferentes áreas da empresa e pensar a partir do ponto de
vista do comportamento esperado de uma funcionalidade pelo
usuário. Por consequência, ele acaba influenciando em como os testes
são planejados e escritos.
TDD - busca garantir a qualidade do código, sempre pensando em 100%
de cobertura de testes, melhorar o que acabou de ser feito e nunca
escrever uma linha de código sem antes pensar em como garantir que
aquilo irá funcionar.
ATDD – Adaptação do TDD para testes de aceitação (validação).
11
 Questão 1
Ano: 2015 Banca: IESES Órgão: TRE-MA Prova: IESES - 2015 - TRE-MA - Técnico Judiciário - Programação de
Sistemas
Qual a alternativa correta a respeito do BDD?
a) Utiliza o conceito de Ubiquitous Language de modo a facilitar o entendimento de todos os fazendo
com que os integrantes falem a mesma língua.
b) É uma técnica de desenvolvimento de testes que funciona exclusivamente se utilizada alguma
metodologia ágil de desenvolvimento.
c) Técnica de testes onde somente os programadores participam, deixando analistas e testadores
cuidando das demais atividades.
d) Maneira de testar os sistemas de acordo com o comportamento esperado, portando só pode ser
feito quando o software estiver concluído.

LETRA A

12
 Questão 2
Ano: 2014 Banca: FCC Órgão: TRT - 2ª REGIÃO (SP) Prova: FCC - 2014 - TRT - 2ª REGIÃO III. Objetiva capturar os critérios de aceitação para as funcionalidades em
(SP) - Analista Judiciário - Tecnologia da Informação desenvolvimento. Trabalha com as seguintes etapas:
Há diversos processos e práticas ágeis de desenvolvimento de software.
Considere: - Discutir (Discuss): discussão colaborativa com a equipe visando elicitar os critérios
de aceitação.
- Refinar (Distill): refinamento dos critérios de aceitação em um conjunto concreto
I. Seu objetivo é criar um “código limpo que funcione”. Trabalha com a de cenários/exemplos de uso descrevendo o comportamento esperado da
estratégia Red - Green - Refactor: aplicação em uma linguagem comum a todos os membros da equipe.
- Desenvolver (Develop): transformação dos testes de aceitação (descrevendo o
- Codifique o teste; comportamento esperado do software) em testes/especificação automatizados.
- Faça-o compilar e executar. O teste não deve passar (Red).
- Implemente o requisito e faça o teste passar (Green). IV. Suas práticas incluem:
- Refatore o código (Refactor).
- Envolver as partes interessadas no processo através de Outside-in Development.
II. Suas práticas, regras e valores garantem um agradável ambiente de - Usar exemplos para descrever o comportamento de uma aplicação ou unidades
desenvolvimento de software para os seus seguidores, que são de código.
conduzidos pelos princípios básicos: - Automatizar os exemplos para prover um feedback rápido e testes de regressão.
- Usar o verbo deve (should) ao descrever o comportamento de software para
ajudar a esclarecer responsabilidades e permitir que funcionalidades sejam
- Comunicação - manter o melhor relacionamento possível entre clientes e questionadas.
desenvolvedores, preferindo conversas pessoais a outros meios de - Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na
comunicação; colaboração entre módulos e códigos que ainda não foram escritos.
- Simplicidade - implementar apenas requisitos atuais, evitando adicionar
funcionalidades que podem ser importantes somente no futuro;
- Feedback - o desenvolvedor terá informações constantes do cliente e do
código, em que testes constantes indicam os erros tanto individuais quanto Os processos ágeis I, II, III e IV são, correta e respectivamente,
do software integrado; denominados:
- Coragem - encorajar as pessoas que não possuem facilidade de a) BDD - DDD - ATDD – XP
comunicação e bom relacionamento interpessoal, encorajar a equipe a
experimentar e buscar novas soluções, além de encorajar a obtenção b) TDD - BDD - DDD – XP
de feedback do cliente. c) ATDD - XP - DDD – BDD
d) ATDD - BDD - TDD – DDD
e) TDD - XP - ATDD - BDD
LETRA E
13
 Gabarito

Questão Resposta
1 LETRA A
2 LETRA E

14
 Continua...
• Kanban
• Outros Tópicos Relevantes

15
 Referências

• PRESSMAN, Roger S. ; Bruce R. Maxim. Engenharia de Software, Uma Abordagem Profissional, 8° ed.
Porto Alegre: AMGH, 2016. ISBN 978-85-8055- 533-2.
• SOMMERVILLE, Ian. Engenharia de Software, 9. ed. São Paulo: Pearson Prentice Hall, 2011. ISBN 978-
85-7936-108-1.

16