Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com Visual Studio 2019.

Workshop BDD com Visual Studio 2019.

Contatos
Professor: Fabrício Leonard Leopoldino, Me
E-mail: fabricioleonard@gmail.com
Site: www.developeracademy.com.br / www.developeracademy.dev

Momento de reflexão
Código limpo que funciona – agora. Essa é a aparente
contradição causadora de grande parte da dor de programar.
O desenvolvimento guiado por testes responde a essa
contradição com um paradoxo – teste o programa antes de
escrevê-lo.
Kent Beck

Quanto custa um bug de software?
6

Você sabe a
diferença entre
erro, defeito e
falha?
17
ERRO: É UMA AÇÃO
HUMANA QUE
PRODUZ UM
RESULTADO
INCORRETO (E PODE
SER COMETIDO EM
QUALQUER FASE DO
DESENVOLVIMENTO
).
DEFEITO: É A
MANIFESTAÇÃO DE
UM ERRO NO
SOFTWARE,
TAMBÉM
CONHECIDO COMO
BUG E SE
EXECUTADO, O
DEFEITO PODE
CAUSAR UMA
FALHA - É O
RESULTADO DO
ERRO COMETIDO.
FALHA: DIFERENÇA
INDESEJÁVEL ENTRE
O OBSERVADO E O
ESPERADO (DEFEITO
ENCONTRADO)

Arranhando a
superfície do
ovo!
19

Resposta
• Para entender como funciona,
• Manter a documentação atualizada,
• Treinamento de novos integrantes,
• Facilitar a manutenção do código,
• Segurança na evolução do código,
• Encontrar um bug,
• Garantir que o software funciona,
• Etc.
24

Tipos de Teste
• Configuração
• Instalação
• Integridade
• Segurança
• Unidade
• Integração
• Volume
• Performance (carga, stress,
estabilidade)
• Usabilidade
• Caixa branca e Caixa preta
• Regressão
• Manutenção
25

METODOLOGIAS ÁGEIS
• Pair Programming
• Passos de Bebê
• Refactoring
• Test Driven Development - TDD
• Behaviour Driven
Development

PAIR
PROGRAMMING
A programação pareada (ou programação em par) é
uma técnica de desenvolvimento de software ágil em
que dois programadores trabalham juntos em uma
estação de trabalho. Um deles, o controlador, escreve
o código, enquanto o outro, chamado de observador
(ou navegador), analisa cada linha do código. Os dois
programadores geralmente trocam de papel
frequentemente.

PAIR
PROGRAMMING
Evitando distrações e criando um ambiente
colaborativo, em geral, a programação pareada se
prova ser mais produtiva do que a isolada. Enquanto
está analisando, o observador também considera a
orientação estratégica do trabalho, dando ideias para
melhorias e comenta sobre possíveis problemas
futuros que devem ser resolvidos. Isso libera o
controlador para concentrar toda a sua atenção nos
aspectos táticos da tarefa atual.

PASSOS DE BEBÊ
Quando um bebê está aprendendo a caminhar
ele não arrisca dar passos grandes por aí. No
desenvolvimento de software, seria
interessante, acontecer da mesma forma. O
código vai saindo devagar, ajudando para que
todos estejam entendendo o que está
acontecendo e que rumo tudo está tomando.
Sempre que alguém não estiver entendendo o
que está acontecendo, esse tem o direito de
perguntar e se encaixar nos trilhos novamente.

REFACTORING
Refatoração é o processo de modificar um sistema de software
para melhorar a estrutura interna do código sem alterar seu
comportamento externo. O uso desta técnica aprimora a
concepção (design) de um software e evita a deterioração tão
comum durante o ciclo de vida de um código. Esta deterioração é
geralmente causada por mudanças com objetivos de curto prazo ou
por alterações realizadas sem a clara compreensão da concepção
do sistema.

REFACTORING
Outra consequência é a melhora no entendimento do código, o que
facilita a manutenção e evita a inclusão de defeitos. Esta melhora
no entendimento vem da constante alteração do código com
objetivo de facilitar a comunicação de motivações, intenções e
objetivos por parte do programador. É fundamental que o sistema
de software possua testes automatizados para realizar refatoração.
Desta forma, será possível garantir que o comportamento externo
não foi alterado.

REFACTORING
Kent Beck, um dos criadores da Programação
Extrema, afirma que refatoração deve ser
utilizada quando o código cheirar mal (do inglês
bad smells in code). Este conselho bem
humorado indica uma confiança na experiência
de programadores e também ressalta o valor
estético do código, que deve valorizar a clareza e
comunicação.

REFACTORING
Alguns indícios já possuem uma aceitação
ampla para promover refatoração:
• Código duplicado (duplicated code)
• Método longo (long method)
• Classe grande (large class)
• Lista de parâmetros longa (long
parameter list)
• Má indentação(Bad Indentation)

REFACTORING
Um dos livros mais interessante sobre refatoração é
Refactoring: Improving the Design of Existing Code (ISBN
0-201-48567-2) de Martin Fowler, onde são explicados
os conceitos, motivações e uma série de refatorações
descritas passo a passo. Programação extrema tem
refatoração como uma de suas práticas.

Test Driven
Development - TDD
Test Driven Development (TDD) ou em
português Desenvolvimento Guiado por
Testes é uma técnica de desenvolvimento de
software que se relaciona com o conceito de
verificação e validação e se baseia em um
ciclo curto de repetições.

Requisitos
Desenvolvimento dirigido por testes requer
dos desenvolvedores criar testes de unidade
automatizados que definam requisitos em
código antes de escrever o código da
aplicação. Os testes contém asserções que
podem ser verdadeiras ou falsas.

Requisitos
Após as mesmas serem consideradas verdadeiras
após sua execução, os testes confirmam o
comportamento correto, permitindo os
desenvolvedores evoluir e refatorar o código.
Desenvolvedores normalmente usam
Frameworks de testes, como xUnit, para criar e
executar automaticamente uma série de casos de
teste.

CICLO DE DESENVOLVIMENTO
1. Adicione um teste.
2. Execute o teste antes de começar a implementar o código, ele tem que falhar
3. Se você sabe que o teste vai passar, você não precisa dele.
4. Não escreva código sem que um teste peça.
5. O teste passou, verifique se o código pode ser refatorado.
6. Repita tudo!

Mantra do TDD
• Vemelho – escrever um pequeno teste que não funcione e que talvez nem mesmo
compile inicialmente.
• Verde – fazer rapidamente o teste funcionar, mesmo cometendo alguns pecados
necessários no processo.
• Refatorar – eliminar todas as duplicatas criadas apenas para que o teste funcione.

Sugestão de Leitura
44
O Codigo Limpo, ensina ao leitor a distinguir um bom código de
um ruim, como escrever bons códigos e transformar códigos
ruim em bom, como criar bons nomes, boas funções, bons
objetos e classes, como formatar o código para ter uma boa
legibilidade, como implementar o tratamento de erro sem
obscurecer a lógica do códigos, com o aplicar testes de unidade
e praticar o desenvolvimento dirigido por testes.

45
O Codificador Limpo" o autor não utiliza códigos, o livro é sobre a
conduta do programador como profissional. As dicas do autor são
das mais variadas, desde adotar TDD (Test Driven Development)
como técnica de desenvolvimento à assistir ou ler Romances
Fictícios para manter a criatividade em alta.

46
A "Arquitetura Limpa" de Martin não é só mais um catálogo de
opções. Com base em meio século de experiência nos mais
variados ambientes de software, Martin indica as escolhas que
você deve fazer e explica por que elas são cruciais para o seu
sucesso. Como já era esperado do Uncle Bob, este livro está cheio
de soluções simples e diretas para os desafios reais que você
enfrentará - aqueles que irão influenciar diretamente o sucesso ou
fracasso dos seus projetos.

Coding Dojo é uma reunião em torno de
um desafio de programação em que as
pessoas são incentivadas a participar e
compartilhar suas habilidades de
codificação com o público enquanto
resolvem o problema.

Estas reuniões levam este nome porque
são inspiradas no Dojos de artes
marciais, no qual dois lutadores
aprendem na prática enquanto os outros
lutadores aprendem observando.

Um dos princípios do Coding Dojo é criar
um ambiente seguro, colaborativo, não
competitivo e que junte pessoas com
vários níveis de habilidade, para testar
novas ideias permitindo o aprendizado
contínuo

Algumas regras gerais do Coding Dojo devem ser seguidas
para que a reunião seja produtiva:
• Sala com espaço e cadeiras suficientes para todos os
participantes
• Em geral necessita-se de um projetor e apenas um
computador (a quantidade de computadores vai
depender do formato de reunião escolhido);
• Um quadro branco para esboçar e projetar
discussões;
• Um problema a ser resolvido, normalmente um
problema de lógica;
• Determinar o tempo que a reunião irá durar,
geralmente dura de 1h a 1:30h .

No início de cada reunião os
participantes discutem sobre o problema
que será solucionado e qual linguagem
de programação será utilizada. Um dos
participantes exerce a função de
organizador, denominado Sensei.

Formatos
• Kata
• Randori
• Kake

Dojo Kata
É utilizado apenas um computador ligado a um
projetor, um ou mais participantes já resolveram o
desafio utilizando TDD e baby steps antes da reunião.
A solução é apresentada a plateia durante a reunião, o
apresentador começa mostrando a solução desde o
início, explicando cada etapa. É permitido que a plateia
faça perguntas ou sugestões a qualquer momento da
apresentação. Ao final da apresentação todos os
participantes devem estar aptos para a reproduzir as
etapas e resolver o mesmo problema após a reunião;

Dojo Randori
Apenas um computador ligado a um projetor é utilizado, a
cada 5 a 7 minutos dois participantes juntam-se para
resolver o problema proposto, explicando o processo para
a plateia. Para desenvolver a solução utiliza-se o TDD. Um
dos participantes é o piloto que comanda o
desenvolvimento do código, enquanto o copiloto aponta
os erros e o que pode ser melhorado. Os outros
participantes não ajudam até que um teste passe ou até
um pedido de ajuda. Ao final do tempo o copiloto torna-
se piloto e algum membro da plateia assume o papel de
copiloto. O dojo encerra quando o desafio é solucionado
ou quando o tempo definido acaba.

Dojo Kake
É uma variação do formato Randori, utiliza diversos
computadores e, em cada um, uma dupla deve
resolver um problema diferente ou o mesmo problema
em linguagens diferentes. As rotações ocorrem dentro
da dupla e entre duplas. Ao término do ciclo, o piloto
torna-se copiloto em outro computador e o copiloto
torna-se o piloto, ficando responsável por explicar ao
copiloto o problema que está sendo resolvido. Neste
caso não existe plateia.

Vantagens
O Coding Dojo é um ambiente seguro para testar
novas ideias, promover o networking e
compartilhamento de ideias entre os membros
da equipe. É muito comum empresas
promoverem Dojos abertos. Dessa forma a
empresa pode conhecer profissionais que
possam se adequar ao seu ambiente e os
profissionais também tem a oportunidade de
conhecer o ambiente dessas empresas.

Vantagens
A troca de conhecimento estimulada pelo Coding Dojo,
serve não só para o ambiente acadêmico, como forma
de facilitador/acelerador de aprendizado como
também serve no âmbito das empresas. Sabe-se que
várias pessoas com conhecimentos e experiências
diferentes trabalham na mesma equipe e utilizar o
dojo nestes ambientes gera um compartilhamento de
conhecimento, agregando maior valor as equipes e
com isto beneficiando tanto a empresa como o
colaborador.

O objetivo de se realizar um Coding Dojo é a diversão.
Desafiar programadores com novos problemas, novas
linguagens, enfim, buscar novas soluções saindo da zona de
conforto.
O Dojo não é uma competição sobre quem resolve o
problema mais rápido, ou qual solução é melhor
implementada.
Obviamente o conhecimento obtido durante a execução do
Coding Dojo é utilizado pelos programadores nas tarefas de
seu dia a dia, o que faz com que a qualidade do trabalho
real produzido também aumente, de forma indireta, com a
realização de Coding Dojos.

❑ Cooperação
❑ Participação
❑ Coragem
❑ Respeito
❑ Simplicidade

No final do Coding Dojo, normalmente, os
participantes realizam uma retrospectiva do evento.
Nessa retrospectiva, que pode ser realizada utilizando
diversas técnicas, de maneira geral são respondidas
três perguntas básicas:
• O que aprendemos com o Coding Dojo de hoje;
• O que podemos melhorar para a realização dos
próximos Coding Dojos;
• O que devemos continuar fazendo nos
próximos Coding Dojos.

A retrospectiva é extremamente
importante, pois condensa todo o
aprendizado do Coding Dojo. Alguns times
costumam registrar os Coding Dojos
realizados (através de filmagens, atas, etc)
para consultas futuras. Essa é uma prática
extremamente interessante, pois permite
que o aprendizado seja compartilhado por
mais pessoas mesmo após a realização do
Coding Dojo.

Fonte de
Exercícios
para Dojos
67

OBSERVAÇÕES
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.
Enquanto o 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.

CONCLUSÃO
Logo podemos concluir que: A técnica BDD
não vai contra o TDD, ou melhor que um
complementa o outro, onde pode aplicar
ambos os métodos em conjunto para uma
melhor segurança ou apenas um deles.
Ambos buscam melhorar o desenvolvimento
de software e são ideias muito bacanas para
se ter em qualquer empresa/projeto.
69

Inicio da Reunião
Discursão sobre o problema!
• O problema!
• A formato!
• As ferramentas!
• As explicações de como foi resolvido.

92
Adicionar nova classe no projeto FizzBuzz

Ciclo do TDD
96
1 - O teste tem que falhar!

Ciclo do TDD
105
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!

Ciclo do TDD
108
3 – Refatore o código!

Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
110

Ciclo do TDD
112

Ciclo do TDD
114
mantendo os demais!

Ciclo do TDD
118

Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
120

Ciclo do TDD
122

Ciclo do TDD
124
mantendo os demais!

Ciclo do TDD
126

Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
128

Ciclo do TDD
130

Ciclo do TDD
132
mantendo os demais!

Ciclo do TDD
134

Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
136

Ciclo do TDD
138

Ciclo do TDD
140
mantendo os demais!

Ciclo do TDD
142

Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
144

Ciclo do TDD
146

Ciclo do TDD
148
mantendo os demais!

Ciclo do TDD
150

BDD
O Behavior Driven Development (BDD) é uma abordagem que consiste em definir o comportamento de um
recurso através de exemplos em texto simples. Esses exemplos são definidos antes do início do
desenvolvimento e são usados como critérios de aceitação. Eles fazem parte da definição de feito. Esses
exemplos apoiam a conversa e ajudam a equipe funcional cruzada (marketing, produto cliente,
desenvolvedor, patrocinador...) a criar um entendimento compartilhado do que deve ser desenvolvido. Essa
é uma ótima maneira de minimizar o desperdício e evitar o desenvolvimento de recursos que ninguém
deseja ou que não atendem às expectativas de negócios.
154

CRIADOR DO BDD
Foi originalmente concebido em 2003, por Dan North, como uma
resposta ao TDD, tem se expandido muito assim como DDD e TDD.
Site: https://dannorth.net/

Usando o BDD com a sintaxe do Gherkin
O Gherkin é uma linguagem de texto simples com uma
estrutura extra projetada para ser fácil de aprender por não
programadores. Ele permite a descrição concisa de
exemplos para ilustrar regras de negócios na maioria dos
domínios do mundo real. Uma das grandes vantagens é que
ele destaca claramente a intenção do exemplo / teste.
160

SpecFlow é um framework inspirado no Cucumber e Gherkin, ou seja, podemos
descrever cenário reais de uso de forma estruturada. Também é possível descrever
nossos cenários em diversos idiomas, com suporte desenvolvimento orientado a
comportamento. Onde podemos defir testes automáticos no Gherkin e executá-los
os usando MSTest, NUnit, xUnit e MbUnit.
164

192
Projeto: BDDFizzBuzz.Teste

241
Compartilhamento de conhecimento: por conta da união entre
desenvolvedores, testers e Stakeholder para desenvolver o
software, um transmite conhecimento para o outro e torna a
equipe mais coesa tecnicamente;
Documentação dinâmica e orgânica: as equipes não possuem
mais desculpa para não documentar o sistema. O BDD
promove a documentação dinâmica do sistema sem qualquer
esforço a mais;
Comunicação entre equipes: geralmente, nas empresas de
engenharia de software, é difícil ver desenvolvedores e testers
trabalhando juntos, contudo, a BDD incentiva a comunicação
entre as equipes.
Observações sobre o BDD

242
Nós da Developer Academy agradecemos a sua
presença, até a próxima!

Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com Visual Studio 2019.

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com Visual Studio 2019.

Semelhante a Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com Visual Studio 2019. (20)

Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com Visual Studio 2019.