Latest / Entre Chaves / #220 TDD e BDD: código rápido ou solução com menos bugs?

Transcript

#220 TDD e BDD: código rápido ou solução com menos bugs? · Entre Chaves

0:02
E está começando mais um entre chaves, o seu podcast de
0:07
desenvolvimento de software. Eu sou a Rafa e no episódio de
0:10
hoje a gente vai falar sobre um assunto que pode ser
0:12
controverso, porque todo mundo, ou pelo menos a gente espera,
0:16
né? Que todo mundo concorda em
0:17
testar, mas nem todo mundo concorda em como testar.
0:20
E uma das metodologias de teste mais famosas, a gente sabe que é
0:24
OTDDEA, gente, também tem um outro, uma outra metodologia que
0:27
é OBDD, que também gera aí. Uma certa dúvida, né?
0:31
O pessoal confunde muito e pra isso, né?
0:33
Eu trouxe aqui o meu colega de bancada, o Ângelo.
0:37
E aí, Rafa, vamos desmistificar toda essa esse mundo de
0:41
qualidade de software aí de TDDEBDDE, vamos falar um
0:44
pouquinho sobre outros conceitos a mais aí também.
0:45
E também a gente está aqui com a Amanda, que é deve, e o Jonathan
0:49
que é QA, né? 2 especialistas aí que vão
0:51
brigar aí hoje. E aí, pessoal?
0:53
E aí, tudo bem? E aí, gente, vou apresentar aqui
0:56
rapidinho. Eu sou o Jonathan, estou atuando
0:57
como QA aqui na DTI tem uns 3 anos.
1:00
Um presente mais? Boa.
1:01
Mas vamos na paz hoje. Vamos.
1:03
Vamos ver se a gente chega num consenso.
1:05
É, a gente sabe que são, né, assuntos aí que gera muitas
1:07
opiniões, né? Mas assim, primeiro de tudo, né,
1:10
vamos pelo menos falar da dessas siglas aí que são meio confusas.
1:13
OTDD é teste driving, development, EOBDD, você troca
1:18
aí para o behaview, né? E aí eu queria que vocês
1:21
contextualizassem essas 2 siglas, já dando uma breve
1:25
contextualização e também no que que elas se diferenciam.
1:28
Vamos começar pelo TDD. Gente, pelo menos se
1:30
contextualizar que a gente está falando de uma metodologia de
1:33
desenvolvimento e não simplesmente do jeito como a
1:35
gente vai escrever 11 história ou como a gente vai testar.
1:38
Isso diz muito a respeito da da cultura que vai ser aplicado no
1:41
time e nos processos que a gente vai rodar como um time.
1:44
Então, basicamente OTDD, ele vai partir do princípio de que a
1:47
gente rode o teste antes do desenvolvimento nossa, mas isso
1:51
não vai falhar. Todos os testes, sim, ele vai
1:53
falhar, mas a ideia é que realmente o teste falhe, mas que
1:56
a gente identifica esses cenários no começo e depois a
1:58
gente faça os ajustes. Necessários que ele passe e
2:01
depois a gente aprimora ele enquanto OBDD.
2:04
Ele vai partir de uma premissa diferente.
2:05
A ideia do BDD é, na verdade, que a gente consiga pensar no
2:08
comportamento como um todo. E a partir desse comportamento,
2:11
a gente gere testes que consigam testar AA possibilidade desejada
2:15
para garantir uma expectativa que seja cumprida.
2:19
Algumas diferenças também que podem causar entre eles.
2:21
Vai ser na escrita da história e que vai ser um pouquinho
2:23
diferente também. Mas a gente vai falar um pouco
2:25
mais sobre isso ao longo da crise.
2:27
Eu gosto quando Jonathan comenta que muita gente acha que.
2:30
EOTDD é simplesmente fazer o teste antes, né?
2:32
Claro que isso é uma parte importante da metodologia, mas
2:35
não é só isso, né? Quando a gente fala sobre TDDA,
2:38
gente, tem aquela aquele ciclo, né, de primeiro fazer o Red,
2:42
depois o green, depois Oo rifactor, né?
2:44
Tem alguma cor pra esse pro rifactor?
2:46
Geralmente ele é marronzinho o amarelo.
2:48
É isso, mas não é simplesmente fazer o teste primeiro e pronto.
2:52
Só isso. E depois não revisitar, não
2:55
voltar a refaturar, organizar e melhorar o seu código.
2:58
Então, OTDD vai um pouco. Além de simplesmente fiz o teste
3:01
primeiro e o código depois. OTDD vai além disso, né, Amanda?
3:04
Tem algo mais a completar aí nesse nesses conceitos iniciais?
3:07
Ah, eles também, né? Ele meio que obriga o princípio
3:10
da responsabilidade única, porque a pessoa tem que fazer um
3:13
teste pequenininho Pra Ele quebrar, depois implementa
3:16
aquele pedacinho, depois faz a faturação dele.
3:19
E aí ao longo prazo, a pessoa ela meio que é obrigada a fazer
3:21
pequenas coisinhas no código. Ela não pode fazer lá uma classe
3:24
gigantesca com um Monte de coisa que No No final, quando ficar
3:28
escava, não vai ficar bem problemático.
3:30
Até para manutenção. As famosas Gold classes nas
3:33
classes que faz tudo que elas linguiciona a classe de 1000
3:35
linhas, né? É isso que você falou do
3:37
acoplamento também, né? Eu acho que ele impede muito que
3:40
o seu teste ele fique. Quando você constrói o código
3:42
primeiro e depois eu fazer o teste, o teste ele é orientado
3:45
pelo seu código, né? E aí muitas vezes ele está tão
3:47
acoplado que AA qualidade do teste cai, a manutenção do teste
3:51
fica mais difícil e essa parte de boas práticas de
3:54
implementação de teste é tão importante que no clicode tem um
3:56
capítulo só pra falar disso, né? E o.
3:58
Legal também é que quando a gente fala de.
4:00
De TDD esse todo esse ciclo que a gente está falando, né?
4:02
De primeiro fazer o Red, depois o green, que primeiro o teste
4:05
que fale, depois o teste que passa e depois se você voltar e
4:08
refaturar tem um outro jeito fácil da gente falar isso né?
4:10
Primeiro você faz de qualquer jeito que é o que o teste que
4:13
vai quebrar, depois você faz o certo que aí o teste vai passar,
4:16
depois você faz melhor porque tudo que você faz na segunda, na
4:18
terceira vez você faz melhor, tudo que você faz na primeira
4:21
vez você faz ali desvendando um mistério, abaixando o Mato,
4:25
aprendendo como é que vai ser o comportamento ali depois quando
4:28
você volta e refaz aquilo? Você faz melhor, então OTDD te
4:31
obriga a isso, né? E entra um pouco do que Amanda
4:33
falou também. Ele te obriga a fazer isso em
4:35
pequenas partes do código também, sempre trazendo solid
4:38
ali no princípio da responsabilidade única, que é OS
4:40
do solid. EOTDD meio que te obriga te
4:43
força ou ou pelo menos te orienta a isso, né?
4:46
Pra usar uma palavra um pouco melhor aqui, né?
4:48
Então assim, né? Do jeito que a gente está
4:49
falando aqui, parece que é tudo uma maravilha.
4:51
Mas por que que os stakeholders? Muitas vezes, em geral, o time
4:55
de produto de negócios é tão resistente, com testes em geral
4:59
e com OTDD. Eu acho que dos times que eu já
5:02
participei, os stakeholders nem eram os mais resistentes.
5:05
Eu já vi muito desenvolvedor resistente a fazer OTDD aí não
5:09
sei se é a minha experiência só ou se o Jonathan e a Amanda tem
5:13
percepções diferentes aí. Concordo, eu acho que deve é
5:16
meio empolgado. Daí ele pega uma testa que fala
5:18
eu quero fazer, eu quero terminar e depois eu testo.
5:20
Então você chega na dele e é muito comum o pessoal falar, Ah,
5:22
eu já terminei o desenvolvimento, agora falta só
5:24
os testes. Então você vê que todo mundo
5:26
desenvolve antes e faz o teste depois.
5:29
Eu acho que é é mais. Do time mesmo porque o pessoal
5:31
tem a ideia de que isso demora mais às vezes que é mais
5:34
complexo. Às vezes o pessoal pensa que é
5:36
desnecessário. Aí você falou, todo mundo faz
5:38
teste, mas eu acho que o pessoal fala assim, Ah, eu tenho que
5:40
fazer o teste. Por isso eu vou fazer não.
5:41
O porquê eu tenho que fazer. Até complementando a Amanda, é
5:45
porque a perceção que a gente tem, quando a gente implanta um
5:49
pouquinho de TDD, é literalmente a diminuição da velocidade, né?
5:52
A gente tem até o dado que diminui em média 15% ali de
5:56
velocidade e tal. Mas OA questão é que a gente não
5:58
compara com o ganho. O que a gente tem porque a gente
6:01
não não consegue medo de ficar Oo bug que nunca existiu.
6:04
Então a grande diferença que a gente vai ganhar de tempo é anão
6:08
geração desse desse bug. Só que não tem como medo de
6:11
ficar para comparar, né? Quanto tempo você gastando um
6:13
bug que existe? Não, não dá para.
6:15
Comparar no médio que não aconteceu, né?
6:17
O que não existiu. Mas eu acho que isso é um bom
6:19
argumento que a gente pode ter com o pessoal de produto, que é
6:22
justamente o tempo que os times em geral, né, gastam com bugs,
6:27
resolução de de chamado, né? De sustentação.
6:30
São, ou então você sobe uma coisa em produção ali, né?
6:33
Às vezes, né, você tem que subir sexta-feira e aí aquilo sai do
6:36
controle, porque é uma coisa que você alterou ali.
6:38
Por exemplo, você tem que alterar uma formatação de um
6:41
campo ali que está errado naquele contexto.
6:43
Mas aí quando você sobe a produção, você descobre que
6:45
aquela formatação era daquele jeito, porque em outro pedaço do
6:49
sistema, nada a ver era daquele jeito.
6:51
E o que resolve? Em teoria, isso é os testes, né?
6:53
Os testes bem feito, EODDD que Visa você construir os testes da
6:57
forma correta, né? E eu acho que.
7:00
E é exatamente esse o ponto, é construir bons testes.
7:03
A qualidade dos dos testes é é o ponto chave, independente se
7:07
você está seguindo OTDD ou não. Porque a frase que a Amanda
7:09
falou ali, de que muita gente chega na dele e fala assim, Ah,
7:13
já terminei, agora falta só os testes, Ah, cara, isso é isso, é
7:16
clássica. E muita gente faz teste
7:19
simplesmente para cobrir a cobertura.
7:21
A gente define lá no sonar que vai ter 80 ou 90% de cobertura
7:24
de testes, e maioria dos testes que eu vejo são testes que estão
7:28
ali simplesmente para cobrir a cobertura.
7:30
Teste de Gate 7. Os testes mais simples
7:32
possíveis, só pra poder cobrir a cobertura.
7:34
E não é essa a ideia do do TDD, né?
7:37
TDD inclusive. Uma das coisas que ele prega é
7:38
isso, partido de você voltar e refaturar é, é justamente pra
7:41
isso, pra você fazer um bom teste, garantir a qualidade pra
7:43
não acontecer isso que a Rafa falou que Jonathan falou aí
7:45
também de ter problemas com qualidade, né?
7:47
O negócio é assim, se diminui a um pouco a velocidade, pode até
7:50
diminuir um pouco a velocidade, mas aumenta a qualidade do
7:53
código que está sendo entregue, né?
7:54
Entrega mais valor no final das contas pro seu cliente.
7:57
É seu famoso, você só tem certeza que seu código está
7:59
funcionando. Você tem um bom teste para ele.
8:01
E aí, igual já não, tu falou, Ah, é difícil medir que tempo
8:04
que você não gastou com um Bang novo.
8:06
Mas se você for parar para olhar a um Squad que está começando e
8:09
ainda não não implementou testes, pessoal geralmente faz
8:11
ali um MPE, depois começa a fazer testes.
8:13
Você vê que o tempo gasto com sustentação antes é muito maior
8:16
do que o tempo depois que a galera começou a fazer teste.
8:18
Então você vê que mesmo que pouco mais tarde, isso tem uma
8:22
diferença. Eu acho que um ponto também, né,
8:24
relacionado aos stakeholders, é que um time de produto, uma
8:28
pessoa de produto, ela não deveria.
8:30
Ser responsável por dizer se você pode ou não.
8:32
Você deve ou não implementar alguma metodologia de teste.
8:35
Eu acho que isso é da responsabilidade do
8:37
desenvolvedor. Ele estabeleceu um prazo que
8:40
inclua a desenvolvimento dos testes e que inclua A Entrega
8:44
com qualidade e não você esperar.
8:46
Ah, vamos desenvolver tudo, entregar rápido aqui, porque tem
8:49
que ser do jeito mais rápido. E aí depois, quando estiver
8:52
homologando, a gente começa aqueles débito técnico de teste.
8:54
E tem 2, né? Porque tem o primeiro, que é o
8:57
que o pessoal não entendeu, o que que era para fazer que a
8:59
pessoa não entende. Entendeu a regra de negócio e
9:01
tem o pessoal entendeu o que era pra fazer, mas fez o código que
9:03
não funciona direito. Então eu acho que isso meio que
9:05
puxa também OOBDD, que é meio que eles Oo desenvolver dele,
9:08
fica mais ciente do que que ele tem que fazer e como ele tem que
9:11
fazer, como que tem que funcionar para ele fazer ali um
9:14
teste, depois ele começar AA fazer o desenvolvimento mais
9:17
orientado para o para o que ele quer.
9:18
Então vamos explorar um pouco mais.
9:20
Aí você falou do BDD, que traz um pouco o time de
9:23
desenvolvimento mais perto do time de negócio.
9:25
Pelo entendimento do que deve ser feito, pelo entendimento do
9:28
que é a tarefa, pelo entendimento do que é a.
9:30
Tonalidade, né? Vamos trazer um pouco mais de
9:31
detalhe. Como que funciona OBDD então?
9:34
Ele meio que surgiu para tornar OODDD mais simples, que é vai
9:38
ajudar o pessoal de desenvolvimento.
9:40
E o pessoal, né? De produto a resolver os
9:42
problemas que estão relacionados com as diferenças de
9:44
desenvolvimento e comportamento da aplicação.
9:46
E a ideia é que eles meio que conversem Na Na mesma língua.
9:49
Então não é uma coisa que é muito técnica só para o pessoal
9:52
de desenvolvimento, mas também não é uma coisa que é muito só
9:54
pessoal de produtos, que conhece mais o negócio.
9:57
E é isso. Eu acho que o que liga
9:59
justamente. E é os desenvolvedores e as
10:01
pessoas de negócio, é justamente o propósito do BDD, é OBDD, ele
10:05
é feito pra que a gente seguir a partir de comportamento, só que
10:08
a maneira como ele faz isso, ela começa da escrita, então OBDD,
10:12
ele parte o princípio que as histórias vão ser escritas em
10:14
garking, que é o formato lá, dado que em, por exemplo, dado
10:17
que o usuário esteja Na Na tela de login, quando ele inseriu um
10:21
login válido, então deve fazer login com sucesso.
10:23
É uma linguagem que todo mundo entende, beleza?
10:25
Eu entendi que eu entrei na página, eu vou lá fazer meu
10:27
login, e funcionou Oo que como era esperado.
10:30
Porém, quando a gente fala de TDDA, gente vai falar um
10:32
pouquinho mais técnico EEA compreensão disso, ela se torna
10:35
diferente. Então, ao invés de ser quando o
10:38
usuário estiver Na Na tela, dado que o usuário esteja na tela de
10:40
login, quando o login forme e os Enem receber uma streaming no
10:47
formato e-mail arroba provider, não sei o que lá e esse user
10:50
Enem tiver no banco de dados, então deve retornar tudo, por
10:54
exemplo, aí a gente consegue destrinchar um pouco mais esses
10:57
cenários, mas a gente fala numa língua muito mais técnica.
11:00
E de muito mais difícil acesso às pessoas de negócio.
11:03
Então a compreensão entre as pessoas do time ela fica menor.
11:06
A minha experiência acaba que os projetos que acabam usando TDD,
11:09
eles partem de pessoas muito técnicas, uma maioria de pessoas
11:13
técnicas e poucas ou nenhuma pessoa de negócio, né?
11:16
Já eu, talvez 11, projeto de sustentação ou algo nesse
11:18
sentido. O roteiro de teste, então, é uma
11:21
forma de implementar BDD num projeto ou são coisas
11:24
diferentes? Eu Acredito que o roteiro de
11:27
teste, se você fizer num formato que OBDDD.
11:30
Vende lá give o endem, ele pode ser considerado SIM 1 um BDD
11:33
agora, do jeito que a gente você está falando, isso é um roteiro
11:36
de texto que você escreve ali No No Word qualquer, só pra
11:39
documentar ali dentro da sua tarefa para você conseguir
11:41
testar depois, né? Ver se cumpriu o critério de
11:43
aceite e tal. Tratamento de exceção também.
11:46
Coisa desse tipo. Agora, quando a gente fala de
11:49
BDD atualmente, a gente tem ferramentas que quando você
11:54
escreve o seu texto, quando você escreve o seu teste ali no
11:57
formato correto, né? Give o endem ou ou.
12:00
Dado que quando então, né, igual o Jonathan estava falando OBDDAA
12:04
ferramenta gera o código que você tem que usar para conseguir
12:07
testar, então existem ferramentas hoje.
12:10
Aí eu acho que Amanda e Jonathan podem até citar aí as
12:12
ferramentas que vocês já conhecem, usam e tal, mas
12:15
ferramentas que vão um pouco além de só tem um roteiro de
12:17
teste aqui, sabe? Mas já automatiza um pouco do
12:20
processo também, né? Falando em ferramentas que vão
12:23
ajudar a gente nesse processo, a gente tem algumas e eu acho que
12:25
o que é importante a gente entender antes da gente escolher
12:28
uma ferramenta, é entender Oo que que a gente.
12:30
De que é como objetivo, por exemplo, um teste voltado ao
12:32
comportamento, ele geralmente vai ser mais lento de ser
12:35
executado do que um teste feito para rodar em TDD.
12:38
Então, por exemplo, quando a gente está falando de TDDA,
12:40
gente vai testar uma parte muito pequena de um forma de login com
12:43
valor, forma de login com outro valor, e a gente vai fazer um
12:46
teste bem pequeno. Porém, quando a gente fala de um
12:48
teste voltado ao comportamento, a gente vai falar de um teste
12:50
maior e a gente vai ter que abrir uma interface, entrar numa
12:52
página e acessar ali aquele campo e fazer a interação com
12:56
aqueles elementos lá até conseguir é executar o cenário
12:59
que. E a gente pensou inicialmente,
13:01
então assim, partindo da premissa que a gente escolheu o
13:03
nosso, que o nosso objetivo é ser rápido, geralmente a gente
13:06
tende AA optar por testes unitários mesmo.
13:09
Então a gente geralmente, o que vai utilizar alguma coisa em
13:11
torno de 11 geste ou fazer um teste de etário na própria
13:15
ideia, Na Na própria linguagem nativa que a gente está
13:17
executando ali, OA nossa programação, o gyunity, enfim,
13:20
algo menor. Quando a gente tiver falando de
13:23
testes de comportamento, tem uma ferramenta que todo mundo usa.
13:26
Na verdade, quando a gente fala desse tipo de teste, que é o
13:28
cucuumber, o cucuumber. Ele geralmente vai fazer a gente
13:32
ter uma camada extra de de teste, por isso que ele é um
13:35
pouco polêmico, porque todos os métodos que que a gente
13:39
desenvolve, a gente tem que importar num arquivo do cucuber
13:42
pra poder utilizar num arquivo de featuring pra conseguir
13:45
executar aquele comportamento. Então você acaba meio que
13:47
kodando 2 vezes e isso torna ele devagar em relação aos testes do
13:52
do. Tdd então, com isso tudo que o
13:54
Jonathan falou dessas ferramentas, a gente percebe
13:56
também que você pode usar o cucuber, mas pode usar o Jay
13:59
Unity também. Você pode usar BDDE, pode usar
14:02
OTDD. Acho que são bons exemplos aí de
14:04
que eles são complementares, né? Perfeito.
14:06
Voltando um pouco no TDD, uma coisa que quando a gente estava
14:09
comentando sobre as equipes, né, eu vejo muitas pessoas, muitos
14:14
deves que eles são relutantes porque eles falam que Ah, como é
14:18
que eu vou saber como implementar o meu teste se eu
14:21
nem sei ainda como o meu código vai ser, né?
14:24
Eu nem sei o que que eu vou fazer no meu código.
14:25
Queria que vocês tentassem, como que vocês convenceriam essa
14:28
pessoa a. Testar OTDDE também se essa
14:32
conceção está errada. Eu acho que pra pessoa fazer o
14:35
código dela também tem que pensar um pouquinho de como ela
14:37
vai fazer. Da mesma maneira.
14:38
Ela precisaria de pensar como ela vai fazer um teste.
14:41
Porque quando eu fazer um código, eu falo, o que que eu
14:42
espero que ele faça? Então, Oo teste, ela faria a
14:45
mesma coisa. O que que eu espero que isso
14:47
faça? É um bom argumento, uma coisa
14:48
também. Eu até faço um paralelo aqui com
14:50
as artes, né? Na escrita, por exemplo, tem
14:52
muitos é autores que quando eles começam a escrever, eles usam
14:56
aquele método. Jardineiro, né?
14:57
Quem é fã de Game of Thrones sabe que o George a.
15:00
Martin, ele escreve dessa forma, então ele não planeja o que ele
15:03
vai escrever, ele simplesmente deixa a história, né, se auto
15:06
guiar. E aí tem outros autores que eles
15:09
planejam cada etapa da história e depois escreve e muitas vezes.
15:13
Agora ele voltando para a programação, eu acho que nós
15:16
deves a gente, somos muitos jardineiros, né?
15:18
E aí acho que OTDD ele vem para mudar um pouco, porque ao invés
15:21
de você ficar rodando, aí você lembra o putz, esqueci o campo
15:24
de CPF aqui Na Na minha API que eu estou construindo, aí você
15:28
tem que ir lá alterar o código aí.
15:30
E você testa de novo. Aí descobre aí que você esqueceu
15:32
outra coisa. Aí você volta lá e altera.
15:34
Então acho que a ideia é você pensar tudo nisso antes de você
15:37
começar a acordar, né? É que nem quando a gente está
15:39
aprendendo. Lá na faculdade, no curso, o
15:41
pessoal falou assim, olha, você tem sempre que programar com o
15:43
papelzinho do lado que você tem que saber o que que você vai
15:46
usar, o que que você quer e um teste de mesa ali de como que
15:49
seu, seu seu código vai funcionar.
15:51
Quando o pessoal vai desenvolver, eles tem que ter
15:53
também um pouquinho, pensar no o que que espera.
15:55
Se não é bem claro que a pessoa talvez não entendeu o que tinha
15:57
que fazer, que aí puxa um pouco de pode, se você não.
16:00
Entendeu a regra de negócio que você vai construir?
16:02
Não, não tem, porque você começa.
16:04
Voltando naquilo que a gente estava falando, né?
16:05
De forçar o planejamento da sua implementação.
16:09
Você garante um código mais limpo, garante que você está
16:11
seguindo os melhores padrões, porque você está pensando mais
16:14
sobre aquilo. Você está voltando, fazendo de
16:15
novo, né? É até.
16:16
Legal que quando é, a gente pega sobre essa parte do da
16:20
implementação dentro do time. Meio que é importante a gente
16:24
analisar o contexto. Acho que o contexto ele vai
16:26
dizer muito dentro dessas implementações da das metas.
16:30
Ideologias e tal. E o ágio?
16:31
Ele é basicamente sobre implementar e testar.
16:33
Então, por exemplo, OTDD, ele vem com a premissa de diminuir
16:37
bugs a custo de 15% ali em média da sua velocidade.
16:41
Só que Oo seu time tem um problema com bugs, ou será que o
16:44
seu time ele produz menos bugs com uma é produzindo as
16:48
histórias ali utilizando um BDD com um entendimento melhor entre
16:53
o time de negócio e o time de desenvolvimento.
16:55
Se o entendimento da galera está bom e eles estão conseguindo
16:59
desenvolver. Ver e isso está achando poucos
17:02
ou com nenhum bug? Então OBDD acaba servindo melhor
17:05
para aquele time, né? Agora, se o time produz muitos
17:07
bugs, então talvez seja necessário a gente voltar na
17:10
base do Spring e se adaptar. AA pop primórdia ali do Spring
17:14
vem sobre adaptação, né? Então quando o time se adapta e
17:17
vê, olha, estou com muitos bugs, o que a gente pode fazer, né?
17:20
E Nessas Horas é muito importante a gente, a gente ter
17:22
domínio sobre essas metodologias e o que a gente pode fazer,
17:25
porque uma implementação de uma metodologia, TDD, num time que
17:28
tem muito, tem muitos bugs. Pode ajudar bastante, né?
17:31
Assim como um time que tem pouco entendimento do negócio, um BDD
17:34
pode ajudar bastante também. Basta saber como a gente
17:36
aplicar. Bom, você falou um negócio ali
17:38
que eu eu estranhei. Assim, reduz em 15% a velocidade
17:41
do time. Mas isso aí é uma métrica ruim,
17:43
né? Assim como é que essa
17:45
compensação aí é isso mesmo. Então, depende.
17:48
Se a gente está falando de 15% de de redução na velocidade,
17:52
tudo depende do quanto o de bug a gente vai reduzir.
17:54
Se a gente tem um índice de bugs, por exemplo, cada 2
17:57
histórias a gente gera um bug. Por exemplo, o índice de bugs.
18:00
Ele está alto, a gente vai ter muitos bugs, então se a gente
18:02
conseguir reduzir 30% disso, já é um ótimo ganho, né?
18:07
Então a média de diminuição de bugs que a proposta do TDD traz
18:12
pra gente é de em torno de 20 a 30%, então você gasta 15, mas
18:16
você ganha de de 20 a 30 em bugs e então tudo depende, né?
18:19
Do quanto quanto de bugs você tem e não só a quantidade, até
18:23
para galera não ver de forma genérica, ver um número alto e
18:25
falar, não precisamos implantar OTDD, às vezes você tem 200 bugs
18:29
no sistema e os dos. 200 vão ser o texto está um Pixel para
18:32
esquerda, o título está um pouquinho para direita.
18:35
Ah, esse aqui não está exatamente alinhado.
18:37
Então, assim, se a gente vai falando de bugs de baixa
18:40
severidade, então nem nem sempre esse ganho vai se justificar só
18:44
por uma diminuição desses, desse número.
18:46
Então, é importante a gente tomar em consideração 2 fatores,
18:49
é que é a quantidade e a severidade desses.
18:51
Bancos a importância de calcular esses números, né?
18:53
Porque se você não tem esse isso aí para essas métricas, para
18:56
você poder provar, vai ser difícil você mostrar o valor de
18:59
forma subjetiva. E outra coisa também, quando Oo
19:02
sistema é pequeno, né? Maravilhoso, você tem a poucos
19:04
bugs, você tem um código pequeno, só que pensando um
19:07
pouco em escalabilidade, quanto maior o sistema ficar, mais bugs
19:11
você poderia ter e teria mais demorado porque pensa os outros,
19:15
vai ficar lá horas e horas procurando, investigando o que
19:17
que está acontecendo, que aquilo ali ficou errado e a boa prática
19:20
que o outro DD meio que obriga, que a gente comentou que é fazer
19:22
as coisas pequenininha, ela evita esse tipo de coisa, então
19:25
você pensa também, Ah, um sistema legado, Ah, 11 time de.
19:30
Apresentação com o pessoal que acabou de pegar ele.
19:32
É muito mais fácil para pessoa que está chegando também
19:34
entender como que as coisas funcionem e fazer um ajuste caso
19:37
seja necessário, ou fazer alguma implementação de alguma fritura
19:40
inova que ela vai se encaixar melhor do que numa coisa que
19:43
seria ali enorme. O que você está?
19:45
Querendo dizer então que o teste ele também é uma documentação,
19:48
né? Do seu projeto?
19:49
Interessante isso que o Jonathan falou, vou trazer uma frase aqui
19:52
que diz assim que se os programadores não estão
19:55
interessados no domínio, eles aprendem apenas o que a
19:58
aplicação deve fazer e no. Não os princípios por trás dela.
20:01
Então o software útil. Ele pode até ser desenvolvido
20:03
dessa maneira, mas o projeto nunca vai chegar num ponto onde
20:06
as funcionalidades mais poderosas surgirão como
20:09
desdobramento natural das funcionalidades existentes,
20:12
porque os programadores não aprenderam o princípio que está
20:16
por trás ali, a regra de negócio.
20:17
E esse é um livro do Eric Evans, que é um livro famosíssimo
20:21
também de uma outra sigla super parecida aqui, que é ADDD, que é
20:24
o do main drive in design. Vai ficar difícil de decorar
20:27
tudo, Hein? DDD é 31, como é que é?
20:30
Esse domind drive design. Agora, quando a gente fala de
20:34
design, nesse caso, para ficar bem claro, assim é o design, é o
20:37
é o projeto, é o que você está pensando para arquitetura, é
20:40
como você está desenhando o seu sistema ali, né?
20:43
E se você está fazendo uma arquitetura, um sistema
20:46
orientado pelo seu domínio, esse domínio, no caso, é o que a
20:49
gente vem falando aqui da lógica de negócio, é o que a gente vem
20:53
falando aqui que OBDD ajuda a gente, aproxima os filmes de
20:56
desenvolvimento e negócio, né? Porque é um domínio, não é?
21:00
Aquela coisa onde o desenvolvedor cria uma tabela
21:02
usuário, que que representa esse usuário usuário, se você tiver
21:04
numa numa aplicação de uma faculdade, pode ser um aluno,
21:07
pode ser professor, pode ser secretário, pode ser qualquer
21:10
coisa. Então usar termos comuns entre o
21:14
time do desenvolvimento e o time de negócio é um pouco do que
21:17
defende ODDD, tem até um, eles têm um conceito lá de linguagem
21:20
umbico, aqui defende muito isso. EE funciona bem, né?
21:23
Assim como o Jonathan deu alguns exemplos aí agora também, né?
21:27
O Jonathan comentou dos 15%, trouxe alguns dados aqui é que.
21:30
E na verdade o tempo de desenvolvimento ele pode
21:32
aumentar de 15 a 35%, né? Então é um, é um, é um tempo
21:34
considerável. Só que a gente tem uns outros
21:36
dados interessantes aqui, não vou citar nomes aqui, mas tem 11
21:40
varejista que reduziu mais de 40% dos defeitos pós
21:43
implantação, depois que adotou ODDD é a Microsoft, essa gente
21:47
pode citar não, não tem problema, aumentou o código, a
21:50
qualidade do código deles quase 4 vezes, não sei qual a qual, a
21:53
exatamente, qual a meta que eles usaram, mas eles afirmaram que
21:56
aumentaram em 4 vezes a qualidade do código e isso
21:59
depois de adotar o. E tem uma aqui que é
22:00
interessante, que teve uma fintech que acelerou o ciclo de
22:03
lançamento em 30% ao adotar ODDD.
22:06
Então AA se acelerar o ciclo de lançamento de uma startup cara,
22:10
é um valor incalculável, porque o timing é extremamente
22:14
importante dentro de startups, né?
22:16
Empresas que estão começando, que tem que lançar logo o
22:18
produto, que tem que testar logo.
22:19
E aí a gente pode citar todos os outros conceitos do agilismo que
22:22
a gente conhece, né? De experimentar, errar, sentir e
22:24
responder. Se você tem uma velocidade maior
22:26
para entregar o seu produto, de testar mais rápido o seu
22:29
produto. Você vai corrigir ele mais
22:31
rápido também e vai melhorar ele mais rápido também, né, ó, tem
22:34
um negócio. Legal sobre isso, que quando a
22:36
gente fala dessas empresas, a gente tá falando de big techs, a
22:39
gente tá falando de Microsoft, a gente tá falando de IBM que
22:41
implementam OTDD dentro dos próprios processos, né?
22:44
E Microsoft, que tem produtos gigantes, IBM que tem produtos
22:47
gigantes também. Mas ainda assim a gente ainda
22:50
tem algumas polêmicas nacionais, né?
22:52
Até em torno dessa implementação, né?
22:54
Muita gente a gente acaba vendo em alguns fóruns, por exemplo,
22:57
de que não vamos implementar TDD porque é uma coisa.
23:00
A gente fica muito na ideia e a gente não consegue fazer isso.
23:02
Não temos exemplos nacionais Fortes disso, mas acaba que tudo
23:07
é sobre uma resolução de problemas, né?
23:08
Então, assim, se a gente partir do princípio, conseguir atuar,
23:12
tem tudo pra dar certo, né? Mas depende da nossa atuação,
23:15
tá? E a gente sabe da dificuldade.
23:16
Que a gente tem no mercado, nós estamos aqui fazendo a nossa
23:18
parte, né, trazendo números, dados, comprovando aí a eficácia
23:22
desses, dessas metodologias para tentar convencer, motivar os
23:26
nossos ouvintes a usarem mais isso, melhorarem a qualidade dos
23:29
seus corpos. Códigos de melhorarem os
23:31
processos, melhorarem a comunicação com o time de
23:33
negócios com OBDD, né? Acho que esse é um benefício
23:36
difícil de calcular em número também, né?
23:38
O quanto que você ganhou melhorando a qualidade da
23:40
comunicação entre David EPO, sabe?
23:42
É difícil traduzir isso em números, né?
23:44
Mas não deixa de ser um benefício, né?
23:46
Eu acho que às vezes. Também até pensando em uma
23:48
métrica de produto que seria o sensat, né?
23:50
De satisfação uma pessoa quando ela está usando um sistema
23:53
principalmente igual a gente comentou, Ah, a startup, alguma
23:55
coisa nova e ela encontra lhe um bug, perde um pouco a
23:57
credibilidade que a pessoa fica assim, Ah, isso aqui está.
24:00
Não tá estragada. Tô zoada, não vou usar, não.
24:01
Você desiste, né? Desinstala o aplicativo
24:04
exatamente. Então, às vezes, até nisso ajuda
24:07
Na Na Na adesão dos usuários ao produto boa bem.
24:10
Lembrado e tem algum case assim que vocês atuaram, que foram
24:13
implementados? BDD ou TDD ou os 2 assim tem um
24:17
case? Um case até um pouco trágico,
24:19
que a galera entendeu que OBDD era o caminho certo, que era de
24:22
111 avião. E aí a funcionalidade do avião
24:26
era voar. Só que a galera esqueceu de
24:27
exercitar esses cenários com OTDDE.
24:29
Acabou com a. Avião voou, mas ele caiu.
24:31
Esqueceram de fazer a gente 8 de terça.
24:33
Era uma piada. Apesar.
24:36
Disso a gente tem diversas aplicações, né?
24:39
Então, assim, a gente precisa entender aonde a gente quer
24:41
chegar para conseguir implementar.
24:42
Quando a gente fala de algumas aplicações, tipo no caso,
24:46
aplicações de aviação, que são um pouco delicadas, a gente tem
24:50
que testar muitos cenários. É uma coisa bem delicada.
24:52
Geralmente a gente opta por um TDD, por uma questão de
24:55
segurança, né, para conseguir garantir mais testes ali. 11
24:58
segurança maior e. Como vocês já falaram, a
25:01
credibilidade, né? Do do cliente em torno desse,
25:04
desse produto, desse serviço. Agora tem alguns cenários que a
25:06
gente tá falando de que o comportamento talvez seja um
25:09
pouco mais interessante, que, por exemplo, a gente tem algumas
25:11
aplicações de restaurante que OBDD, acaba sendo bem
25:14
interessante do tipo, o usuário tem que ser capaz de adicionar
25:18
um produto no carrinho, ele tem que ser capaz de fazer no login,
25:20
então acaba que OBDD se torna um pouco mais didático nesse tipo
25:23
de aplicação. Então só alguns exemplos, né?
25:26
A gente tem alguns produtos de restaurante aqui, já que OBD tem
25:29
sido. Mostrado muito bom e tem algumas
25:31
aplicações mais sensíveis, como aplicações bancárias e tudo mais
25:34
que OTDD tem se mostrado um pouco melhor.
25:37
O contexto vai dizer bastante sobre a aplicação das
25:40
metodologias aí. E, mais que tudo, eu acho que em
25:43
algum momento isso tudo se complementa e que é a parte mais
25:46
legal de tudo. Então você, por exemplo, a gente
25:48
faz alguns testes usando OTDD ali, fazendo os testes
25:51
unitários, bonitinho, antes de desenvolver a aplicação.
25:54
Mas isso não precisa eliminar o fato de que a gente vai fazer
25:57
alguns testes utilizando BDD também.
25:59
Então, e. Enquanto deve, por exemplo,
26:01
estar desenvolvendo os testes em TDD ali bonitinho, fazendo 11
26:04
aumento da cobertura no gesto e tudo mais, a gente pode
26:07
colaborar com os demais membros do time, por exemplo, que chamar
26:10
o pessoal de Kia para incrementar alguns testes
26:12
utilizando o cumber. E aí essas 2 coisas acabam se
26:15
juntando e trazendo um nível de qualidade de código muito
26:18
melhor, uma confiabilidade melhor e por consequência, um
26:21
sucesso maior do produto ali, confiança do cliente e tudo
26:23
mais. Uma dúvida, Jonathan.
26:24
A gente deveria adotar então um BDD somente quando a gente tem
26:29
um time de. QAA pergunta é porque quando
26:31
você citou aí sobre OTDD, você citou o último desenvolvimento.
26:34
Quando você citou OBDD, você citou o time de QA.
26:37
Então existe essa divisão a quem faz OBDDA galera do QA.
26:42
Quem faz OTDD é a galera do desenvolvimento ou tanto faz?
26:45
Não necessariamente. A gente precisa segmentar isso,
26:48
tá? Tudo depende do entendimento e
26:50
do resultado que a gente consegue gerar a partir disso.
26:52
Então, por exemplo, quando a gente tá falando em TDD, vamos
26:54
ter uma linguagem mais técnica. Isso não impede da gente ter um
26:58
QA ou não, tudo que vai. Para que está?
27:00
Na verdade é se o que a entende, o que está ali ou não.
27:03
Porque a proposta do BDD, ela é sobre comunicação, é sobre
27:06
entendimento do negócio, facilitar com que os deves EE,
27:09
as pessoas ter negócio, consigam se comunicar ali sobre o que as
27:13
funcionalidades devem fazer ou não.
27:15
Então se a gente fazendo um TDD ali, como o processo do time e
27:20
os deves estarem entendendo isso e os que as também, a gente
27:23
consegue seguir numa boa. Agora, se a gente não consegue
27:26
ter essa comunicação clara e efetiva para garantir OA
27:29
funcionalidade. Idade, como ela deve estar
27:31
funcionando? Então talvez seja interessante a
27:33
gente abordar as coisas com OBDD, então a parte muito da
27:36
comunicação, nossos ouvintes. Estão ouvindo aí sobre TDDBDDE?
27:40
Estão curiosos por onde começar? Vocês têm algum livro, alguma
27:43
boa referência? E aí a gente pode até colocar
27:46
essas referências aí na descrição do episódio junto com
27:49
o nosso link. Quem quiser acessar lá nosso
27:51
link de vagas, nosso link de newsletter, fique à vontade
27:54
também na descrição. Tá bom, eu acho que os próprios.
27:56
Livros que você comentou do Eric acho que são os mais comuns,
27:59
assim, quais são? Lugar que a gente pesquisa,
28:01
comenta sobre eles, tem mais um também.
28:02
Que é pouco famoso, que é o manifesto ágil.
28:05
O manifesto ágil acaba alincando bastante com a proposta não só
28:09
de uma, mas das 2 metodologias, das 3.
28:11
Na verdade que a gente falou do DDD também, né?
28:13
Então o manifesto ágil ele representa muito disso, né?
28:16
Que tem a uma premissa lá que a nossa maior prioridade é
28:19
satisfazer do cliente através da entrega contínua e adiantada de
28:23
software com valor agregado. E mais do que isso, as pessoas
28:26
de negócios e desenvolvedores devem trabalhar diariamente em
28:28
conjunto por todo o. Projeto, ou seja, desde que a
28:31
gente consiga trabalhar em equipe e entregar valor.
28:33
A gente vai entregar 111. Bom software é um manifesto
28:36
argem aí pra gente demais. Ou, na verdade?
28:39
Faltou a gente falar de último assunto, né?
28:41
OOGDD conhece? AI meu Deus, que que é isso?
28:44
Gambiarra driven. Developman é uma brincadeira
28:47
essa eu vejo. Várias, todo dia.
28:50
Ou só só uma dúvida também, se vocês já ouviram falar no ATDD
28:55
daí, esse esse é. Piada ou não, não, esse é.
28:57
Sério mesmo? Axetans teste driven develop.
29:00
A gente já ouviram falar nisso, é na prática, não muda.
29:02
Muito é porque assim, basicamente você está falando de
29:04
níveis de teste diferente. Enquanto um a gente vai
29:07
representar programaticamente em teste unitário, o outro a gente
29:10
vai ter que fazer um teste dentro da interface.
29:13
Então, apesar dessa diferença pequena, que é o nível do teste,
29:16
e isso acaba impactando Na Na velocidade de execução e de
29:19
implantação, esse teste é um é um pouquinho mais caro, um
29:22
pouquinho mais lento, mas no final faz a mesma coisa, mas
29:25
você aproxima um. Pouco do BDD também, né?
29:27
Sim, vai ser bem próximo. Então eu acho que é isso a
29:29
gente. Explorou.
29:30
Tem os conceitos aqui de TDDBDDA gente, sabe agora que OTDD tem
29:34
uma linguagem mais técnica, OBDD, tem uma linguagem mais de
29:37
negócios. Temos boas referências aí, que
29:39
são os livros do do Eric Evans, né?
29:41
Pra gente poder começar no assunto, pra gente poder começar
29:44
a experimentar nos times. E temos boas métricas para
29:47
justificar esse começo, para justificar esse uso, né?
29:50
Mesmo que às vezes a gente possa perder um pouco na velocidade, a
29:53
gente ganha muito na qualidade, ganha muito na entrega de valor
29:56
para os nossos clientes, né? Então eu queria agradecer
29:58
Jonathan e Amanda aí pela parte. Participação eu que agradeço.
30:01
Obrigada obrigadão gente. Um prazer participar aí com
30:04
vocês, então é isso aí, pessoal. Valeu, Rafa, valeu.
30:07
Até a próxima.