[Script Info] Title: [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:00.00,0:00:03.88,Default,,0000,0000,0000,,No capítulo cinco, uma visão geral sobre testes. Este Dialogue: 0,0:00:03.88,0:00:07.81,Default,,0000,0000,0000,,este é Brian Kernighan, o autor, um dos Bell Labs, heróis que o autor do Dialogue: 0,0:00:07.81,0:00:12.06,Default,,0000,0000,0000,,livro Kernighan e Ritchie [inaudível] que provalmente a moria de vocês tiveram. Dialogue: 0,0:00:12.06,0:00:16.41,Default,,0000,0000,0000,,it's, if you read it a couple, you can get it. A depuração é duas vezes mais difícil que escrever Dialogue: 0,0:00:16.41,0:00:20.61,Default,,0000,0000,0000,,o código no [inaudível]. Portanto, é duas vezes mais difícil, certo? Então, portanto, se você Dialogue: 0,0:00:20.61,0:00:24.80,Default,,0000,0000,0000,,escrever o código mais inteligente pela primeira vez, você nunca vai ser capaz de depurá-lo, Dialogue: 0,0:00:24.80,0:00:30.07,Default,,0000,0000,0000,,porque é duas vezes mais rígido. Tudo bem, este, este é um teste Dystra e você tem que Dialogue: 0,0:00:30.07,0:00:36.09,Default,,0000,0000,0000,,preencher o vazio. Teste pode nunca demonstrar a. Ausência de ar, é só pa. Dialogue: 0,0:00:36.09,0:00:41.04,Default,,0000,0000,0000,,Presença, certo ? Bem, isso é, que existe há muito tempo, e Dialogue: 0,0:00:41.04,0:00:46.70,Default,,0000,0000,0000,,só tenho que manter isso em mente. Aqui está um artigo que saiu um ano e meio Dialogue: 0,0:00:46.70,0:00:51.92,Default,,0000,0000,0000,,atrás e ele diz que por isso são coisas caras. E você pode ver aqui que o seu estudo Dialogue: 0,0:00:51.92,0:00:56.82,Default,,0000,0000,0000,,não é que não há bugs e [inaudível] no design, é apenas recursos de teste ruins, Dialogue: 0,0:00:56.82,0:01:02.11,Default,,0000,0000,0000,,péssimos , os processos de testes ruins são razões que que lá está, há tantos Dialogue: 0,0:01:02.11,0:01:07.01,Default,,0000,0000,0000,,erros no código. E aqui diz que ambientes de testes totalmente automatizados Dialogue: 0,0:01:07.01,0:01:11.53,Default,,0000,0000,0000,,são raros. Isto foi um ano e meio atrás Ainda assim, nós somos apenas 20, 12 por cento Dialogue: 0,0:01:11.53,0:01:16.71,Default,,0000,0000,0000,,do software das organizações [inaudível] têm sistemas de testes totalmente automatizados. Dialogue: 0,0:01:16.71,0:01:21.02,Default,,0000,0000,0000,,Dez por cento fazer todos os testes manualmente. Certo ? Então você escrever o teste. Você olha para a Dialogue: 0,0:01:21.02,0:01:25.22,Default,,0000,0000,0000,,saída. Você escreve o teste. Olhe para a saída. Veja todos os erros? Ok. Então uau Dialogue: 0,0:01:25.22,0:01:29.85,Default,,0000,0000,0000,,não posso acreditar que, isso, isso ainda é verdade. Isso não é verdade aqui. [risos]. Você Dialogue: 0,0:01:29.85,0:01:35.09,Default,,0000,0000,0000,,save ? Você sabe para Agile antes da mão, você tem uma equipe separada garantia de qualidade. Então você Dialogue: 0,0:01:35.09,0:01:40.13,Default,,0000,0000,0000,,tem todas essas fases e grupos distintos de pessoas. Então, Marge, de alguma forma, a qualidade Dialogue: 0,0:01:40.13,0:01:44.80,Default,,0000,0000,0000,,a equipe de garantia da qualidade deveria inserir qualidade em seu código. [risos]. Ou se Dialogue: 0,0:01:44.80,0:01:49.73,Default,,0000,0000,0000,,certificar de que você, você tem qualidade no seu código. Com o Agile, é parte de tudo Dialogue: 0,0:01:49.73,0:01:54.26,Default,,0000,0000,0000,,o que fazemos. Estamos testando continuamente. Toda semana, nós trazemos para o novo código. Você Dialogue: 0,0:01:54.26,0:01:58.89,Default,,0000,0000,0000,,é responsável por testar o seu código, e não outra pessoa. E as ferramentas são muito Dialogue: 0,0:01:58.89,0:02:03.82,Default,,0000,0000,0000,,[inaudível] tão diferente que, que a declaração que foi feito antes. E assim que o Dialogue: 0,0:02:03.82,0:02:08.44,Default,,0000,0000,0000,,argumento aqui no [inaudível] o manifesto real é que, se com um bom Dialogue: 0,0:02:08.44,0:02:13.49,Default,,0000,0000,0000,,processo teremos qualidade macia ao invés de há um grupo específico que é suposto Dialogue: 0,0:02:13.49,0:02:20.14,Default,,0000,0000,0000,,assegurar é que eles vão bater em você se você don 't tem. Asim. Bdd e TDD Dialogue: 0,0:02:20.14,0:02:25.64,Default,,0000,0000,0000,,foi que disse anteriormente. O fase Behavior \Ndriven design foi inspirado em algumas pessoas Dialogue: 0,0:02:25.64,0:02:30.86,Default,,0000,0000,0000,,ficando confuso sobre test driven development.Aqui estamos testando os testes de aceitação Dialogue: 0,0:02:30.86,0:02:36.29,Default,,0000,0000,0000,,testes de integração e tentando captar o comportamento. Tdd vai ser definições passo Dialogue: 0,0:02:36.29,0:02:41.85,Default,,0000,0000,0000,,e realmente escrever testes unitários e testes de função, , antes de escrever o Dialogue: 0,0:02:41.85,0:02:47.21,Default,,0000,0000,0000,,código. Então esse é o. Assim, a boa notícia é que você sempre vai ter o teste até Dialogue: 0,0:02:47.21,0:02:52.48,Default,,0000,0000,0000,,até agora porque você está escrevendo o código ou mesmo antes. Então aqui está como eles funcionam Dialogue: 0,0:02:52.48,0:02:56.99,Default,,0000,0000,0000,,juntos. Pepinos descrever o [inaudível]. Você, você começar a escrever Dialogue: 0,0:02:56.99,0:03:01.56,Default,,0000,0000,0000,,as histórias que você deseja. Eles falham. Em seguida, ele chama as implementações, o Dialogue: 0,0:03:01.56,0:03:06.26,Default,,0000,0000,0000,,teste. Se ele falhar, então você, você implementa os métodos que estão Dialogue: 0,0:03:06.26,0:03:10.90,Default,,0000,0000,0000,,faltando. E então, quando ele passa no teste [inaudível], você mantém internamente Dialogue: 0,0:03:10.90,0:03:15.99,Default,,0000,0000,0000,,iteração até passar o [inaudível]. E, em seguida, uma vez que você implementou o Dialogue: 0,0:03:15.99,0:03:20.95,Default,,0000,0000,0000,,recurso de forma adequada, ele, ele vai passar o passo pepino verde e você vai para trás e Dialogue: 0,0:03:20.95,0:03:23.20,Default,,0000,0000,0000,,continuar com o desenvolvimento.