0:00:00.000,0:00:03.877
No capítulo cinco, uma visão geral sobre testes. Este

0:00:03.877,0:00:07.807
este é Brian Kernighan, o autor, um dos Bell Labs, heróis que o autor do

0:00:07.807,0:00:12.055
livro Kernighan e Ritchie [inaudível] que provalmente a moria de vocês tiveram.

0:00:12.055,0: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

0:00:16.410,0:00:20.606
o código no [inaudível]. Portanto, é duas vezes mais difícil, certo? Então, portanto, se você

0:00:20.606,0:00:24.802
escrever o código mais inteligente pela primeira vez, você nunca vai ser capaz de depurá-lo,

0:00:24.802,0:00:30.067
porque é duas vezes mais rígido. Tudo bem, este, este é um teste Dystra e você tem que

0:00:30.067,0:00:36.088
preencher o vazio. Teste pode nunca demonstrar a. Ausência de ar, é só pa.

0:00:36.088,0:00:41.042
Presença, certo ? Bem, isso é, que existe há muito tempo, e

0:00:41.042,0:00:46.700
só tenho que manter isso em mente. Aqui está um artigo que saiu um ano e meio

0:00:46.700,0:00:51.922
atrás e ele diz que por isso são coisas caras. E você pode ver aqui que o seu estudo

0:00:51.922,0:00:56.825
não é que não há bugs e [inaudível] no design, é apenas recursos de teste ruins,

0:00:56.825,0:01:02.110
péssimos , os processos de testes ruins são razões que que lá está, há tantos

0:01:02.110,0:01:07.013
erros no código. E aqui diz que ambientes de testes totalmente automatizados

0:01:07.013,0:01:11.534
são raros. Isto foi um ano e meio atrás Ainda assim, nós somos apenas 20, 12 por cento

0:01:11.534,0:01:16.707
do software das organizações [inaudível] têm sistemas de testes totalmente automatizados.

0:01:16.707,0:01:21.023
Dez por cento fazer todos os testes manualmente. Certo ? Então você escrever o teste. Você olha para a

0:01:21.023,0:01:25.225
saída. Você escreve o teste. Olhe para a saída. Veja todos os erros? Ok. Então uau

0:01:25.225,0:01:29.852
não posso acreditar que, isso, isso ainda é verdade. Isso não é verdade aqui. [risos]. Você

0:01:29.852,0:01:35.086
save ? Você sabe para Agile antes da mão, você tem uma equipe separada garantia de qualidade. Então você

0:01:35.086,0:01:40.133
tem todas essas fases e grupos distintos de pessoas. Então, Marge, de alguma forma, a qualidade

0:01:40.133,0:01:44.805
a equipe de garantia da qualidade deveria inserir qualidade em seu código. [risos]. Ou se

0:01:44.805,0:01:49.727
certificar de que você, você tem qualidade no seu código. Com o Agile, é parte de tudo

0:01:49.727,0:01:54.260
o que fazemos. Estamos testando continuamente. Toda semana, nós trazemos para o novo código. Você

0:01:54.260,0:01:58.888
é responsável por testar o seu código, e não outra pessoa. E as ferramentas são muito

0:01:58.888,0:02:03.816
[inaudível] tão diferente que, que a declaração que foi feito antes. E assim que o

0:02:03.816,0:02:08.444
argumento aqui no [inaudível] o manifesto real é que, se com um bom

0:02:08.444,0:02:13.493
processo teremos qualidade macia ao invés de há um grupo específico que é suposto

0:02:13.493,0:02:20.141
assegurar é que eles vão bater em você se você don 't tem. Asim. Bdd e TDD

0:02:20.141,0:02:25.636
foi que disse anteriormente. O fase Behavior [br]driven design foi inspirado em algumas pessoas

0:02:25.636,0:02:30.859
ficando confuso sobre test driven development.Aqui estamos testando os testes de aceitação

0:02:30.859,0:02:36.286
testes de integração e tentando captar o comportamento. Tdd vai ser definições passo

0:02:36.286,0:02:41.849
e realmente escrever testes unitários e testes de função, , antes de escrever o

0:02:41.849,0:02:47.208
código. Então esse é o. Assim, a boa notícia é que você sempre vai ter o teste até

0:02:47.208,0:02:52.485
até agora porque você está escrevendo o código ou mesmo antes. Então aqui está como eles funcionam

0:02:52.485,0:02:56.992
juntos. Pepinos descrever o [inaudível]. Você, você começar a escrever

0:02:56.992,0:03:01.564
as histórias que você deseja. Eles falham. Em seguida, ele chama as implementações, o

0:03:01.564,0:03:06.265
teste. Se ele falhar, então você, você implementa os métodos que estão

0:03:06.265,0:03:10.901
faltando. E então, quando ele passa no teste [inaudível], você mantém internamente

0:03:10.901,0:03:15.988
iteração até passar o [inaudível]. E, em seguida, uma vez que você implementou o

0:03:15.988,0:03:20.946
recurso de forma adequada, ele, ele vai passar o passo pepino verde e você vai para trás e

0:03:20.946,0:03:23.200
continuar com o desenvolvimento.