1
00:00:00,000 --> 00:00:03,877
No capítulo cinco, uma visão geral sobre testes. Este

2
00:00:03,877 --> 00:00:07,807
este é Brian Kernighan, o autor, um dos Bell Labs, heróis que o autor do

3
00:00:07,807 --> 00:00:12,055
livro Kernighan e Ritchie [inaudível] que provalmente a moria de vocês tiveram.

4
00:00:12,055 --> 00:00:16,410
it's, if you read it a couple, you can get it. A depuração é duas vezes mais difícil que escrever

5
00:00:16,410 --> 00:00:20,606
o código no [inaudível]. Portanto, é duas vezes mais difícil, certo? Então, portanto, se você

6
00:00:20,606 --> 00:00:24,802
escrever o código mais inteligente pela primeira vez, você nunca vai ser capaz de depurá-lo,

7
00:00:24,802 --> 00:00:30,067
porque é duas vezes mais rígido. Tudo bem, este, este é um teste Dystra e você tem que

8
00:00:30,067 --> 00:00:36,088
preencher o vazio. Teste pode nunca demonstrar a. Ausência de ar, é só pa.

9
00:00:36,088 --> 00:00:41,042
Presença, certo ? Bem, isso é, que existe há muito tempo, e

10
00:00:41,042 --> 00:00:46,700
só tenho que manter isso em mente. Aqui está um artigo que saiu um ano e meio

11
00:00:46,700 --> 00:00:51,922
atrás e ele diz que por isso são coisas caras. E você pode ver aqui que o seu estudo

12
00:00:51,922 --> 00:00:56,825
não é que não há bugs e [inaudível] no design, é apenas recursos de teste ruins,

13
00:00:56,825 --> 00:01:02,110
péssimos , os processos de testes ruins são razões que que lá está, há tantos

14
00:01:02,110 --> 00:01:07,013
erros no código. E aqui diz que ambientes de testes totalmente automatizados

15
00:01:07,013 --> 00:01:11,534
são raros. Isto foi um ano e meio atrás Ainda assim, nós somos apenas 20, 12 por cento

16
00:01:11,534 --> 00:01:16,707
do software das organizações [inaudível] têm sistemas de testes totalmente automatizados.

17
00:01:16,707 --> 00:01:21,023
Dez por cento fazer todos os testes manualmente. Certo ? Então você escrever o teste. Você olha para a

18
00:01:21,023 --> 00:01:25,225
saída. Você escreve o teste. Olhe para a saída. Veja todos os erros? Ok. Então uau

19
00:01:25,225 --> 00:01:29,852
não posso acreditar que, isso, isso ainda é verdade. Isso não é verdade aqui. [risos]. Você

20
00:01:29,852 --> 00:01:35,086
save ? Você sabe para Agile antes da mão, você tem uma equipe separada garantia de qualidade. Então você

21
00:01:35,086 --> 00:01:40,133
tem todas essas fases e grupos distintos de pessoas. Então, Marge, de alguma forma, a qualidade

22
00:01:40,133 --> 00:01:44,805
a equipe de garantia da qualidade deveria inserir qualidade em seu código. [risos]. Ou se

23
00:01:44,805 --> 00:01:49,727
certificar de que você, você tem qualidade no seu código. Com o Agile, é parte de tudo

24
00:01:49,727 --> 00:01:54,260
o que fazemos. Estamos testando continuamente. Toda semana, nós trazemos para o novo código. Você

25
00:01:54,260 --> 00:01:58,888
é responsável por testar o seu código, e não outra pessoa. E as ferramentas são muito

26
00:01:58,888 --> 00:02:03,816
[inaudível] tão diferente que, que a declaração que foi feito antes. E assim que o

27
00:02:03,816 --> 00:02:08,444
argumento aqui no [inaudível] o manifesto real é que, se com um bom

28
00:02:08,444 --> 00:02:13,493
processo teremos qualidade macia ao invés de há um grupo específico que é suposto

29
00:02:13,493 --> 00:02:20,141
assegurar é que eles vão bater em você se você don 't tem. Asim. Bdd e TDD

30
00:02:20,141 --> 00:02:25,636
foi que disse anteriormente. O fase Behavior 
driven design foi inspirado em algumas pessoas

31
00:02:25,636 --> 00:02:30,859
ficando confuso sobre test driven development.Aqui estamos testando os testes de aceitação

32
00:02:30,859 --> 00:02:36,286
testes de integração e tentando captar o comportamento. Tdd vai ser definições passo

33
00:02:36,286 --> 00:02:41,849
e realmente escrever testes unitários e testes de função, , antes de escrever o

34
00:02:41,849 --> 00:02:47,208
código. Então esse é o. Assim, a boa notícia é que você sempre vai ter o teste até

35
00:02:47,208 --> 00:02:52,485
até agora porque você está escrevendo o código ou mesmo antes. Então aqui está como eles funcionam

36
00:02:52,485 --> 00:02:56,992
juntos. Pepinos descrever o [inaudível]. Você, você começar a escrever

37
00:02:56,992 --> 00:03:01,564
as histórias que você deseja. Eles falham. Em seguida, ele chama as implementações, o

38
00:03:01,564 --> 00:03:06,265
teste. Se ele falhar, então você, você implementa os métodos que estão

39
00:03:06,265 --> 00:03:10,901
faltando. E então, quando ele passa no teste [inaudível], você mantém internamente

40
00:03:10,901 --> 00:03:15,988
iteração até passar o [inaudível]. E, em seguida, uma vez que você implementou o

41
00:03:15,988 --> 00:03:20,946
recurso de forma adequada, ele, ele vai passar o passo pepino verde e você vai para trás e

42
00:03:20,946 --> 00:03:23,200
continuar com o desenvolvimento.