SlideShare uma empresa Scribd logo
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
Convite
3
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
5
Quanto custa um bug de software?
6
7
8
9
10
11
12
13
14
15
16
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)
18
Arranhando a
superfície do
ovo!
19
20
Por que
testar?
21
22
23
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.
35
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!
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
42
SUGESTÃO DE LIVROS SOBRE TDD
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.
Sugestão de Leitura
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.
Sugestão de Leitura
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.
Como praticar o TDD
47
Como
Treinar
49
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.
Site Oficial
66
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
Demonstração
TDD
Inicio da Reunião
Discursão sobre o problema!
• O problema!
• A formato!
• As ferramentas!
• As explicações de como foi resolvido.
Metodologia
73
O problema
Metodologia
75
Ferramentas
76
A explicação
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
Adicionar nova classe no projeto FizzBuzz
93
94
95
Ciclo do TDD
96
1 - O teste tem que falhar!
97
98
99
100
101
102
103
104
Ciclo do TDD
105
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
106
107
Ciclo do TDD
108
3 – Refatore o código!
109
Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
110
111
Ciclo do TDD
112
1 - O teste tem que falhar!
113
Ciclo do TDD
114
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
115
116
117
Ciclo do TDD
118
3 – Refatore o código!
119
Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
120
121
Ciclo do TDD
122
1 - O teste tem que falhar!
123
Ciclo do TDD
124
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
125
Ciclo do TDD
126
3 – Refatore o código!
127
Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
128
129
Ciclo do TDD
130
1 - O teste tem que falhar!
131
Ciclo do TDD
132
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
133
Ciclo do TDD
134
3 – Refatore o código!
135
Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
136
137
Ciclo do TDD
138
1 - O teste tem que falhar!
139
Ciclo do TDD
140
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
141
Ciclo do TDD
142
3 – Refatore o código!
143
Completou o
ciclo TDD, se
sim passe
para o
próximo
teste!
144
145
Ciclo do TDD
146
1 - O teste tem que falhar!
147
Ciclo do TDD
148
2 – O teste tem que passar de qualquer jeito,
mantendo os demais!
149
Ciclo do TDD
150
3 – Refatore o código!
151
152
153
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/
Processo do
BDD
156
Ciclo BDD
157
Etapas básicas
158
Gherkin
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
Antes de Gherkin
161
Depois de Gherkin
162
Exemplo
163
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
165
SUGESTÃO DE LIVROS SOBRE BDD
Demonstração
BDD
Inicio da Reunião
Discursão sobre o problema!
• O problema!
• A formato!
• As ferramentas!
• As explicações de como foi resolvido.
O problema
Metodologia
171
Ferramentas
17
2
A explicação
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
Apague este arquivo!
190
191
192
Projeto: BDDFizzBuzz.Teste
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
O problema
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
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!

Mais conteúdo relacionado

Mais procurados

Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
Pedro Pereira Martins
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
João Carlos Ottobboni
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
Renato Groff
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
Carlos Henrique Martins da Silva
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
Renato Pina
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
Fernando Kenji Kamei
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
Rennan Martini
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Ricardo Bánffy
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
Daniel Brandão
 
TDD - Test Driven Development com JAVA
TDD - Test Driven Development com JAVATDD - Test Driven Development com JAVA
TDD - Test Driven Development com JAVA
Paulo Igor Alves Godinho
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
Dionatan default
 
TDD para "meros mortais"
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"
thiagobapt
 
TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
Icaro Camelo
 
TDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software ÁgilTDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software Ágil
Bruno Eustáquio
 
Os Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
Dextra Sistemas / Etec Itu
 
TDD
TDDTDD
TDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do TesteTDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do Teste
Aislan Fernandes
 
Tdd na veia
Tdd na veiaTdd na veia
Tdd na veia
Bruno Maomeh
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
Eduardo Mendes
 
XP Programming
XP ProgrammingXP Programming
XP Programming
CJR, UnB
 

Mais procurados (20)

Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
 
Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
TDD - Test Driven Development com JAVA
TDD - Test Driven Development com JAVATDD - Test Driven Development com JAVA
TDD - Test Driven Development com JAVA
 
Introdução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anosIntrodução ao TDD (Test-Driven Development) - #guma10anos
Introdução ao TDD (Test-Driven Development) - #guma10anos
 
TDD para "meros mortais"
TDD para "meros mortais"TDD para "meros mortais"
TDD para "meros mortais"
 
TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
 
TDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software ÁgilTDD - Pós Graduação em Engenharia de Software Ágil
TDD - Pós Graduação em Engenharia de Software Ágil
 
Os Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de softwareOs Benefícios dos testes no desenvolvimento de software
Os Benefícios dos testes no desenvolvimento de software
 
TDD
TDDTDD
TDD
 
TDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do TesteTDD - A Verdadeira Face do Teste
TDD - A Verdadeira Face do Teste
 
Tdd na veia
Tdd na veiaTdd na veia
Tdd na veia
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
XP Programming
XP ProgrammingXP Programming
XP Programming
 

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

Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
Rudson Kiyoshi Souza Carvalho
 
Código limpo php
Código limpo phpCódigo limpo php
Código limpo php
FilipiAtaideArruda
 
Sobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis UberlândiaSobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis Uberlândia
Rogerio Fontes
 
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
tdc-globalcode
 
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
tdc-globalcode
 
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
Joberto Diniz
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
Dionatan default
 
Refactory Worshop
Refactory WorshopRefactory Worshop
Refactory Worshop
guestd37c23
 
Instituto Stela S&T#001, Projeto de software com testes unitários
Instituto Stela S&T#001, Projeto de software com testes unitáriosInstituto Stela S&T#001, Projeto de software com testes unitários
Instituto Stela S&T#001, Projeto de software com testes unitários
Instituto Stela (Florianópolis-SC, Brasil)
 
Coding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente OrganizacionalCoding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente Organizacional
Avelino Ferreira Gomes Filho
 
Subm_SamuelPereira_FINAL
Subm_SamuelPereira_FINALSubm_SamuelPereira_FINAL
Minicurso de TDD
Minicurso de TDDMinicurso de TDD
Minicurso de TDD
William G. Comnisky
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
Robson Silva Espig
 
O que é ser um bom programador?
O que é ser um bom programador?O que é ser um bom programador?
O que é ser um bom programador?
Lucas Boeing Scarduelli
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
ECRAYON Tecnologia Criativa
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
Simone Pittner
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
ceife
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
Gabriel Moura
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
Concurseiro Área de TI
 
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Marcio Miyamoto
 

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

Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
 
Código limpo php
Código limpo phpCódigo limpo php
Código limpo php
 
Sobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis UberlândiaSobre TDD - Tech Friday da Everis Uberlândia
Sobre TDD - Tech Friday da Everis Uberlândia
 
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
 
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
TDC2017 | Florianopolis - Trilha DevOps How we figured out we had a SRE team ...
 
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
A Importância do Código Limpo na Perspectiva dos Desenvolvedores e Empresas d...
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
 
Refactory Worshop
Refactory WorshopRefactory Worshop
Refactory Worshop
 
Instituto Stela S&T#001, Projeto de software com testes unitários
Instituto Stela S&T#001, Projeto de software com testes unitáriosInstituto Stela S&T#001, Projeto de software com testes unitários
Instituto Stela S&T#001, Projeto de software com testes unitários
 
Coding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente OrganizacionalCoding Dojo Aplicado ao Ambiente Organizacional
Coding Dojo Aplicado ao Ambiente Organizacional
 
Subm_SamuelPereira_FINAL
Subm_SamuelPereira_FINALSubm_SamuelPereira_FINAL
Subm_SamuelPereira_FINAL
 
Minicurso de TDD
Minicurso de TDDMinicurso de TDD
Minicurso de TDD
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
 
O que é ser um bom programador?
O que é ser um bom programador?O que é ser um bom programador?
O que é ser um bom programador?
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 
Tdd x testes unidades
Tdd x testes unidadesTdd x testes unidades
Tdd x testes unidades
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Analise e desenvolvimento
Analise e desenvolvimentoAnalise e desenvolvimento
Analise e desenvolvimento
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
Desenvolvimento de software de forma rápida e sem bugs - Introdução a TDD e S...
 

Último

Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
joaovmp3
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
WELITONNOGUEIRA3
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 

Último (8)

Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
Certificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdfCertificado Jornada Python Da Hashtag.pdf
Certificado Jornada Python Da Hashtag.pdf
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 
Manual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdfManual-de-Credenciamento ANATER 2023.pdf
Manual-de-Credenciamento ANATER 2023.pdf
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 

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

  • 1. Workshop BDD com Visual Studio 2019.
  • 2. Contatos Professor: Fabrício Leonard Leopoldino, Me E-mail: fabricioleonard@gmail.com Site: www.developeracademy.com.br / www.developeracademy.dev
  • 4. 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
  • 5. 5
  • 6. Quanto custa um bug de software? 6
  • 7. 7
  • 8. 8
  • 9. 9
  • 10. 10
  • 11. 11
  • 12. 12
  • 13. 13
  • 14. 14
  • 15. 15
  • 16. 16
  • 17. 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)
  • 18. 18
  • 20. 20
  • 22. 22
  • 23. 23
  • 24. 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
  • 25. 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
  • 26. METODOLOGIAS ÁGEIS • Pair Programming • Passos de Bebê • Refactoring • Test Driven Development - TDD • Behaviour Driven Development
  • 27. 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.
  • 28. 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.
  • 29. 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.
  • 30. 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.
  • 31. 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.
  • 32. 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.
  • 33. 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)
  • 34. 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.
  • 35. 35
  • 36. 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.
  • 37. 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.
  • 38. 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.
  • 39. 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!
  • 40. 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!
  • 41. 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.
  • 43. SUGESTÃO DE LIVROS SOBRE TDD
  • 44. 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. Sugestão de Leitura 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. Sugestão de Leitura 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.
  • 47. Como praticar o TDD 47
  • 48.
  • 50. 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.
  • 51. 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.
  • 52. 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
  • 53. 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 .
  • 54. 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.
  • 56. 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;
  • 57. 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.
  • 58. 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.
  • 59.
  • 60. 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.
  • 61. 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.
  • 62. 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.
  • 63. ❑ Cooperação ❑ Participação ❑ Coragem ❑ Respeito ❑ Simplicidade
  • 64. 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.
  • 65. 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.
  • 68. 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.
  • 69. 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
  • 70.
  • 72. Inicio da Reunião Discursão sobre o problema! • O problema! • A formato! • As ferramentas! • As explicações de como foi resolvido.
  • 78. 78
  • 79. 79
  • 80. 80
  • 81. 81
  • 82. 82
  • 83. 83
  • 84. 84
  • 85. 85
  • 86. 86
  • 87. 87
  • 88. 88
  • 89. 89
  • 90. 90
  • 91. 91
  • 92. 92 Adicionar nova classe no projeto FizzBuzz
  • 93. 93
  • 94. 94
  • 95. 95
  • 96. Ciclo do TDD 96 1 - O teste tem que falhar!
  • 97. 97
  • 98. 98
  • 99. 99
  • 100. 100
  • 101. 101
  • 102. 102
  • 103. 103
  • 104. 104
  • 105. Ciclo do TDD 105 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 106. 106
  • 107. 107
  • 108. Ciclo do TDD 108 3 – Refatore o código!
  • 109. 109
  • 110. Completou o ciclo TDD, se sim passe para o próximo teste! 110
  • 111. 111
  • 112. Ciclo do TDD 112 1 - O teste tem que falhar!
  • 113. 113
  • 114. Ciclo do TDD 114 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 115. 115
  • 116. 116
  • 117. 117
  • 118. Ciclo do TDD 118 3 – Refatore o código!
  • 119. 119
  • 120. Completou o ciclo TDD, se sim passe para o próximo teste! 120
  • 121. 121
  • 122. Ciclo do TDD 122 1 - O teste tem que falhar!
  • 123. 123
  • 124. Ciclo do TDD 124 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 125. 125
  • 126. Ciclo do TDD 126 3 – Refatore o código!
  • 127. 127
  • 128. Completou o ciclo TDD, se sim passe para o próximo teste! 128
  • 129. 129
  • 130. Ciclo do TDD 130 1 - O teste tem que falhar!
  • 131. 131
  • 132. Ciclo do TDD 132 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 133. 133
  • 134. Ciclo do TDD 134 3 – Refatore o código!
  • 135. 135
  • 136. Completou o ciclo TDD, se sim passe para o próximo teste! 136
  • 137. 137
  • 138. Ciclo do TDD 138 1 - O teste tem que falhar!
  • 139. 139
  • 140. Ciclo do TDD 140 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 141. 141
  • 142. Ciclo do TDD 142 3 – Refatore o código!
  • 143. 143
  • 144. Completou o ciclo TDD, se sim passe para o próximo teste! 144
  • 145. 145
  • 146. Ciclo do TDD 146 1 - O teste tem que falhar!
  • 147. 147
  • 148. Ciclo do TDD 148 2 – O teste tem que passar de qualquer jeito, mantendo os demais!
  • 149. 149
  • 150. Ciclo do TDD 150 3 – Refatore o código!
  • 151. 151
  • 152. 152
  • 153. 153
  • 154. 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
  • 155. 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/
  • 160. 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
  • 164. 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
  • 165. 165
  • 166. SUGESTÃO DE LIVROS SOBRE BDD
  • 167.
  • 169. Inicio da Reunião Discursão sobre o problema! • O problema! • A formato! • As ferramentas! • As explicações de como foi resolvido.
  • 174. 174
  • 175. 175
  • 176. 176
  • 177. 177
  • 178. 178
  • 179. 179
  • 180. 180
  • 181. 181
  • 182. 182
  • 183. 183
  • 184. 184
  • 185. 185
  • 186. 186
  • 187. 187
  • 188. 188
  • 190. 190
  • 191. 191
  • 193. 193
  • 194. 194
  • 195. 195
  • 196. 196
  • 197. 197
  • 198. 198
  • 199. 199
  • 200. 200
  • 201. 201
  • 202. 202
  • 203. 203
  • 204. 204
  • 205. 205
  • 206. 206
  • 207. 207
  • 208. 208
  • 209. 209
  • 210. 210
  • 211. 211
  • 212. 212
  • 213. 213
  • 214. 214
  • 215. 215
  • 216. 216
  • 217. 217
  • 218. 218
  • 219. 219
  • 220. 220
  • 221. 221
  • 222. 222
  • 224. 224
  • 225. 225
  • 226. 226
  • 227. 227
  • 228. 228
  • 229. 229
  • 230. 230
  • 231. 231
  • 232. 232
  • 233. 233
  • 234. 234
  • 235. 235
  • 236. 236
  • 237. 237
  • 238. 238
  • 239. 239
  • 240. 240
  • 241. 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. 242 Nós da Developer Academy agradecemos a sua presença, até a próxima!