Latest / Entre Chaves / Testes planejados são a solução e não o problema

Transcript

Testes planejados são a solução e não o problema · Entre Chaves

• 0:03
  Eu vejo muitas pessoas, muitos deves que eles são relutantes
• 0:07
  porque eles falam que Ah, como é que eu vou saber como
• 0:11
  implementar o meu teste se eu nem sei ainda como o meu código
• 0:14
  vai ser, né? Eu nem sei o que que eu vou
• 0:16
  fazer no meu código. Queria que vocês tentassem.
• 0:18
  Como que vocês convenceriam essa pessoa a testar o tdd e também
• 0:23
  se essa conceção está errada. Eu acho que pra pessoa fazer o
• 0:26
  código dela também, tem que pensar um pouquinho de como ela
• 0:29
  vai fazer da mesma. Ela precisaria de pensar como
• 0:31
  vai fazer um teste? Porque quando eu fazer um
• 0:33
  código, eu falo, o que que eu espero que ele faça?
• 0:35
  Então, Oo teste, ela faria a mesma coisa.
• 0:37
  O que que eu espero que isso faça é.
• 0:39
  Um bom argumento, uma coisa também.
• 0:40
  Eu até faço um paralelo aqui com as artes, né?
• 0:42
  Na escrita, por exemplo, tem muitos é autores que quando eles
• 0:45
  começam a escrever, eles usam aquele método.
• 0:48
  Jardineiro, né? Quem é fã de Game of Thrones
• 0:50
  sabe que o George or Martin ele escreve dessa forma, então ele
• 0:53
  não planeja o que ele vai escrever, ele simplesmente deixa
• 0:56
  a história, né? Se autoguiar.
• 0:58
  E aí tem outros. Autores que eles planejam cada
• 1:02
  etapa da história e depois escreve e muitas vezes agora ele
• 1:05
  voltando para a programação, eu acho que nós deves a gente,
• 1:08
  somos muitos jardineiros, né? E aí acho que OTD dele vem para
• 1:11
  mudar um pouco, porque ao invés de você ficar rodando, aí você
• 1:14
  lembra o putz, esqueci o campo de CPF aqui Na Na minha API que
• 1:18
  eu estou construindo, aí você tem que ir lá, alterar o código,
• 1:21
  aí você testa de novo, aí descobre aí que você esqueceu
• 1:24
  outra coisa, aí você volta lá e altera.
• 1:25
  Então acho que a ideia é você pensar tudo nisso antes de você
• 1:29
  começar a codar. Ah, né?
• 1:30
  É que nem quando a gente está aprendendo lá na faculdade, no
• 1:32
  curso, o pessoal falou assim, olha, você tem sempre que
• 1:34
  programar com o papelzinho do lado que você tem que saber o
• 1:37
  que que você vai usar, o que que você quer e um teste de mesa ali
• 1:40
  de como que seu, seu seu código vai funcionar.
• 1:42
  Quando o pessoal vai desenvolver, eles tem que ter
• 1:44
  também um pouquinho, pensar no o que que espera.
• 1:46
  Se não é bem claro que a pessoa talvez não entendeu o que tinha
• 1:49
  que fazer, que aí puxa um pouco de pode.
• 1:50
  Se você não entendeu a regra de negócio que você vai construir,
• 1:53
  não, não tem porque você começar.
• 1:55
  Voltando naquilo que a gente estava falando, né?
• 1:57
  De forçar o planejamento da sua implementação.
• 2:00
  Ração você garante um código mais limpo, garante que você
• 2:03
  está seguindo os melhores padrões, porque você está
• 2:04
  pensando mais sobre aquilo, você está voltando fazendo de novo,
• 2:07
  né, é? Até legal que quando é a gente
• 2:10
  pega sobre essa parte do da implementação dentro do time.
• 2:13
  Meio que é importante a gente analisar o contexto.
• 2:16
  Acho que o contexto ele vai dizer muito dentro dessas
• 2:19
  implementações da das metodologias e tal.
• 2:22
  E o ágil, ele é basicamente sobre implementar e testar.
• 2:25
  Então, por exemplo, OTDD, ele vem com a premissa de diminuir
• 2:28
  bugs a custo de. E 15% ali em média da sua
• 2:31
  velocidade. Só que Oo seu time tem um
• 2:34
  problema com bugs, ou será que o seu time ele produz menos bugs?
• 2:38
  Com uma é produzindo as histórias ali utilizando um BDD
• 2:42
  com um entendimento melhor entre o time de negócio e o time de
• 2:46
  desenvolvimento. Se o entendimento da galera tá
• 2:48
  bom e eles estão conseguindo desenvolver e isso está ajudando
• 2:53
  poucos ou com nenhum bug, então OBDD acaba servindo melhor para
• 2:57
  aquele time, né? Agora, se o time produz muitos
• 2:59
  bugs, então. Então, talvez seja necessário a
• 3:01
  gente voltar na base do Spring e se adaptar.
• 3:04
  AA pop primórdia ali do Spring vem sob adaptação, né?
• 3:06
  Então quando o time se adapta e vê, olha, eu estou com muitos
• 3:09
  bugs, o que a gente pode fazer, né?
• 3:11
  E Nessas Horas é muito importante.
• 3:13
  A gente tem a gente ter domínio sobre essas metodologias e o que
• 3:15
  a gente pode fazer, porque uma implementação de uma metodologia
• 3:19
  TDD, num time que tem muito, tem muitos bugs, pode ajudar
• 3:21
  bastante, né? Assim como um time que tem pouco
• 3:24
  entendimento do negócio, um BDD pode ajudar bastante também,
• 3:26
  basta saber como a gente aplicar.
• 3:28
  Bom, você falou um negócio ali que.
• 3:30
  Eu eu estranhei. Assim, reduz em 15% a velocidade
• 3:33
  do time. Mas isso aí é uma métrica ruim,
• 3:35
  né? Assim como é que é essa
• 3:36
  compensação? Aí é isso mesmo.
• 3:38
  Então, depende. Se a gente está falando de 15%
• 3:41
  de de redução na velocidade, tudo depende do quanto de bug a
• 3:45
  gente vai reduzir. Se a gente tem um índice de
• 3:47
  bugs, por exemplo, cada 2 histórias a gente gera um bug.
• 3:50
  Por exemplo, o índice de bugs, ele está alto, a gente vai ter
• 3:52
  muitos bugs. Então se a gente conseguir
• 3:54
  reduzir 30% disso, já é um ótimo ganho, né?
• 3:58
  Então a média de. Diminuição de bugs que a
• 4:01
  proposta do TDD traz pra gente é de em torno de 20 a 30%, então
• 4:06
  você gasta 15, mas você ganha de de 20 a 30 em bugs e então tudo
• 4:10
  depende né? Do quanto quanto de bugs você
• 4:12
  tem e não só a quantidade. Até para galera não ver de forma
• 4:16
  genérica, ver um número alto e falar, não precisamos implantar
• 4:18
  OTDD, às vezes você tem 200 no sistema e os 200 vão ser o texto
• 4:23
  está um Pixel para esquerda, o título está um pouquinho para
• 4:26
  direita. Ah, esse aqui não está
• 4:28
  exatamente alinhado, então assim, se ele.
• 4:30
  A gente vai falando de bugs de baixa severidade.
• 4:33
  Então nem nem sempre esse ganho vai se justificar só por uma
• 4:36
  diminuição desses, desse número. Então é importante a gente tomar
• 4:39
  em consideração 2 fatores, é que é a quantidade e a severidade
• 4:42
  desses bands. A importância de calcular esses
• 4:44
  números, né? Porque se você não tem esse isso
• 4:46
  aí para essas métricas, para você poder provar, vai ser
• 4:48
  difícil você mostrar o valor de forma subjetiva e.
• 4:51
  Outra coisa também quando o sistema é pequeno, né?
• 4:54
  Maravilhoso. Você tem a poucos bug, você tem
• 4:57
  um código pequeno, só que pensando um pouco em
• 4:59
  escalabilidade. E quanto maior o sistema ficar,
• 5:02
  mais bugs você poderia ter e teria mais demorado porque pensa
• 5:06
  os outros, vai ficar lá horas e horas procurando, investigando o
• 5:09
  que que está acontecendo com aquilo ali ficou errado e a boa
• 5:11
  prática que o outro DD meio que obriga que a gente comentou que
• 5:13
  é fazer as coisas pequenininha, ela evita esse tipo de coisa,
• 5:17
  então você pensa também, Ah, um sistema legado, Ah, 11, time de
• 5:21
  sustentação com o pessoal que acabou de pegar ele.
• 5:23
  É muito mais fácil para pessoa que está chegando também
• 5:26
  entender como que as coisas funcionem e fazer um ajuste caso
• 5:28
  seja necessário ou. Fazer alguma implementação de
• 5:31
  alguma fritura inova que ela vai se encaixar melhor do que numa
• 5:34
  coisa que seria ali enorme. O que?
• 5:36
  Você está querendo dizer então que o teste ele também é uma
• 5:38
  documentação, né? Do seu projeto?
• 5:40
  Interessante isso que o Jonathan falou.
• 5:42
  Vou trazer uma frase aqui que diz assim que se os
• 5:45
  programadores não estão interessados no domínio, eles
• 5:48
  aprendem apenas o que a aplicação deve fazer e não os
• 5:51
  princípios por trás dela, então o software útil ele pode até ser
• 5:54
  desenvolvido dessa maneira, mas o projeto nunca vai chegar num
• 5:57
  ponto onde as funcionalidades mais poderosas.
• 6:00
  Surgirão como desdobramento natural das funcionalidades
• 6:03
  existentes, porque os programadores não aprenderam o
• 6:06
  princípio que está por trás ali, a regra de negócios.
• 6:08
  E esse é um livro do Eric Evans, que é um livro famosíssimo
• 6:12
  também de uma outra sigla super parecida aqui, que é ADDD, que é
• 6:16
  o domein driven design. Vai ficar difícil de decorar
• 6:18
  tudo, Hein? DDD é 31, como é que é?
• 6:22
  Esse domein driven design agora, quando a gente fala de design,
• 6:26
  nesse caso, para ficar bem claro, assim é o design, é o é o
• 6:29
  projeto. Certo é o que você está pensando
• 6:31
  pra arquitetura, é como você está desenhando o seu sistema
• 6:34
  ali, né? E se você está fazendo uma
• 6:36
  arquitetura, um sistema orientado pelo seu domínio, esse
• 6:39
  domínio, no caso, é o que a gente vem falando aqui da lógica
• 6:43
  de negócio, é o que a gente vem falando aqui que OBDD ajuda a
• 6:46
  gente, aproxima os filmes de desenvolvimento e negócio, né,
• 6:49
  porque é um domínio, não é naquela coisa onde o
• 6:52
  desenvolvedor cria uma tabela usuário, que que representa esse
• 6:54
  usuário usuário, se você tiver numa numa aplicação de uma
• 6:57
  faculdade, pode ser um aluno, pode ser professor, pode ser.
• 7:00
  Secretário, pode ser qualquer coisa.
• 7:02
  Então usar termos comuns entre o time do desenvolvimento e o time
• 7:07
  de negócio é um pouco do que defende ODDD, tem até um eles
• 7:10
  têm um conceito lá de linguagem. Umbico aqui defende muito isso.
• 7:13
  EE funciona bem, né? Assim como o Jonathan deu alguns
• 7:16
  exemplos aí agora também, né?