[MÚSICA] [MÚSICA] Olá a todos! Esse é o curso de Desenvolvimento de Software Guiado por Testes. Meu nome é Eduardo Guerra e hoje vou estar falando para você sobre o ciclo do TDD. O ciclo do Test Driven Development, certo? Então nessa aula a gente vai entender aí como é que é o andamento do TDD e vai ver como é que funciona aí esse ciclo do TDD, certo? Bom, hoje eu vou fazer as coisas de uma forma diferente, está? Que é que você faz quando você tem uma dúvida nos dias de hoje, não é, uma coisa que você não sabe? Não é, por exemplo no outro dia minha filha chegou para mim e me perguntou: "Pai que é que é uma supernova?" Não é, certo? "Que é que é uma nebulosa?" Não é? Vou ter que [RISOS] não é, dar uma procurada para poder responder corretamente, onde é que você vai? Você vai no Google, está? Então vamos fazer aqui hoje uma abordagem diferente, que a gente vai ver o que é que o Google tem a dizer certo, sobre o ciclo do TDD, não é? Então o que é que é o ciclo do TDD segundo aí o Google, está? Então eu fiz uma pesquisa lá no Google Images e vamos ver o que é que apareceu, está? Bom, uma das figuras que apareceu foi essa daqui está? É, como é que funciona o ciclo? Vamos lá, começa no vermelhinho: você adiciona teste certo e aí você vai rodar esse teste, não é, já passando para o próximo e vai ver ele falhar está? Porque é que você tem que rodar o teste e ver ele falhar? Porque se você tem teste que já está funcionando, então você não precisa fazer mais nada está? O TDD, a motivação que você tem para mexer no código é ter teste falhando está? Então no TDD ele tem essa ideia de que você só vai mexer no código se tiver uma, teste que não está funcionando está? E aí o que é que vai acontecer, você vai lá então, já que tem teste que não está funcionando, você vai lá escrever código, vai mexer no código da aplicação para fazer aquele teste funcionar. Seguida você vai rodar os testes não é, se não funcionou você volta escreve mais o código, mexe no código até aquele teste e todos os outros testes estarem passando está? E aí no final você vai, refatora o código não é, ou seja a gente vai falar pouco mais de refatoração nas próximas aulas, mas o refatorar entenda como melhorar a estrutura do código sem alterar o que ele faz certo? E aí depois você vai e adiciona, depois que está tudo funcionando e está com aquela estrutura bacana, você vai lá e adiciona novo teste, está? Então ele vai nesse ciclo até que todas as funcionalidades que você deseja já estejam ali nos testes, está? Vamos ver o próximo, está? Então ele fala assim: escreva teste que falhe, não é, ele já resumiu, faça esse teste passar, como que você vai fazer esse teste passar? Criando código, não é, indo lá na classe que você quer implementar e criando código para fazer aquele teste passar e depois você vai lá e refatora. Note aqui que na parte de cima a setinha é vermelha, porquê? Porque naquele momento a nossa barrinha lá do JUnit ela está vermelha não é? O teste está falhando e aí nas outras duas depois que o teste passou e depois ali quando você refatora, a barrinha tem que estar verde, ou seja todos os testes têm que estar passando, está? Bom, dizem que para bom entendedor meia palavra basta, então resumindo o ciclo do TDD seria o vermelho, verde, refatora. Vermelho é o quê? Quando você cria teste que está falhando, então está vermelho. O verde é o quê? Você fazer esse teste passar e o refatorar é você melhorar a estrutura mantendo o comportamento. Então resumindo o ciclo do TDD é vermelho- verde- refatora, vermelho- verde- refatora, vermelho- verde- refatora, certo? Eh vamos lá agora para a minha figura favorita, não é, que ganhou aí o prémio de honra aí na busca que eu fiz. É esse cartãozinho aqui. O cara colocou aqui o principal do TDD, não é? Então o vermelho, o teste falha, e aí fica com a carinha triste, fica lá hmmm, não é? Porquê? Porque não está funcionando, o teste não está passando, certo? Aí depois você vai e faz o teste passar e aí você fica feliz porque o seu código está funcionando, então você faz. Você fica lá, não é, na frente do computador. E aí você vai e refatora e aí o seu código não só está passando como ele está com uma ótima estrutura, ele está limpo, ele está claro de ser lido, está sem duplicação e aí você fica mais feliz ainda, não é? Então você estava lá, o teste passou você e aí depois que refatora, você vai ficar dando aquele sorrisão não é e aí até criar novo teste que aí você volta a ficar triste, certo? Mas aí você fica feliz quando faz ele passar, mais feliz ainda quando refatora e volta, mas você não precisa ser aí bipolar nem nada disso para fazer TDD, é só uma pequena brincadeira. Na verdade, quando você cria o teste que falha você não fica tão triste assim porquê? Apesar de não estar funcionando tudo o que você quer, o teste te mostra exatamente o que é que você tem que fazer, então não é tão feliz quanto fazer passar, mas também não é triste porque você sabe o que você precisa fazer agora para fazer o teste passar. Bom, agora que a gente falou do ciclo, eu vou entrar no detalhe de cada desses 3 passos do TDD, está? Então o primeiro passo é adicionar o teste, está? Só que, o que é que é o adicionar o teste? Não é só ir lá no JUnit e pá! Enquanto você faz isso, você está definindo qual que é a interface da classe que você está implementado. Ou seja, você fala assim " eu estou criando aqui uma classe por exemplo, que eu quero que ela mande arquivo através da rede" não é? E aí você fala assim "como é que alguém vai acessar essa classe para fazer isso? Eu vou chamar método connect? Eu vou dar send file já com os dados para onde eu quero que ele mande? Eu vou criar uma conexão, estabeleço, depois eu mando ou eu faço tudo de método só e encerro a conexão, não é? Será que eu vou querer mandar mais de arquivo ao mesmo tempo? Então, nesse momento quando você está criando o teste, você está criando a visão que os seus clientes vão ter da sua classe, está? Então o criar o teste, uma das coisas que você faz é projetar a interface da classe que você está criando, ou seja como quem está de fora enxerga essa classe. E outra coisa que você faz é definir o comportamento dessa classe, e nessa definição de comportamento você diz o que é que vai acontecer depois que você chamar o método. Então se é método que faz cálculo de repente ele vai-te retornar valor, se é uma classe que de repente isso aí vai mudar o estado interno, então você de repente vai chamar outro método para ver qual é aquele estado interno, ou se a classe se comporta não é, da forma que ela deveria se comportar tendo aquele estado interno, está? Então quando você definiu o teste, na verdade o que é que você está fazendo? Você está definindo a interface da sua classe e qual que é o comportamento esperado para ela, está? Bom, quando a gente faz o teste passar, que é o segundo passo, nesse ponto a gente realmente está implementando a classe, não é? A ideia do TDD é não, não se virar e falar assim " eu sei que tenho esse teste mas eu sei quais vão ser os próximos 3 então, eu já vou criar aqui monte de coisas". Não, é você tentar fazer a solução mais simples possível para que aquele teste passe está? E eu, isso aí é uma experiência minha, está, várias vezes eu peguei uma classe para fazer usando TDD e eu pensei, olhando por alto assim os requisitos, eu pensava " vou ter que criar tal coisa, vou ter que fazer desse jeito, daquele outro mas vamos fazer aqui pelo TDD". E aí eu começava fazendo uma solução mais simples, mais simples e aí quando acabavam todos os testes eu via que aquela solução que eu tinha pensado inicialmente, antes de começar a fazer o TDD, era muito mais complicada do que a solução final, não é? Então, realmente essa questão de você buscar a solução mais simples, que faça os teste que você já tem passar e não ficar pensando na frente é uma questão muito importante do TDD, está? Você é, é assim do meu ponto de vista é dos grandes ganhos que você tem TDD, você termina com código limpo, com código fácil de ler, código simples, o mais simples possível para aqueles seus requisitos. E a minha experiência, não é, pela minha experiência eu posso afirmar com certeza, que muitas vezes eu pensei soluções muito mais complicadas, do que aquelas que eu ia fazer, usando o TDD, tá. Bom e a gente vai para o último passo que é a refatoração, tá. Então, quando a gente refatora, o que é que a gente faz, a gente limpa o código que a gente criou. Então o que é limpar? Como eu falei, a gente vai falar sobre refatoração nas próximas aulas aí, na verdade vamos falar bastante de refatoração várias aulas desse curso, mas vou dar alguns exemplos. Por exemplo, você vai lá e cria nome de uma variável que não está muito legal, né. Esse é o momento de você ir lá e mudar o nome daquela variável. Você criou item ali, deu uma duplicada de códigos, ou o método ficou muito grande. É o momento de você ir lá eliminar aquela duplicação, extrair o método, melhorar o nome da variável. É você melhorar o código. E muitas vezes isso acaba mexendo no próprio design da classe, às vezes você começa a implementar e você fala: "opa, essa classe está com código duplicado relação àquela outra. Eu vou criar uma superclasse, vou criar uma biblioteca de classe, o que é que eu vou fazer aqui para esse código ficar melhor." E a vantagem é que você tem os testes como uma segurança, né, como seguro ali, porque se alguma coisa der errado, ele vai te ajudar a detectar isso o mais rápido possível. Ou seja, o pessoal fala, time que está ganhando você não mexe. Agora quando a gente tem os testes, a gente pode mexer e ver se ele vai continuar ganhando, e se a gente tiver uma estrutura melhor, a gente sai ganhando mais ainda, né. Porque quem for mexer naquele código depois, vai ter facilidade, isso vai ajudar na manutenção, são vários os benefícios que têm de você refatorar o seu código com frequência. Tá, eu não poderia falar sobre o ciclo do TDD sem falar sobre os baby steps, né. Olha isso daí, que fofo! Né? Fofinho, né, certo. O que é que a gente vai aprender com esse nenê? A andar devagarzinho, certo? No TDD, não basta você ir lá e fazer ciclo grandão daqueles com monte de testes. A questão, esse ciclo do TDD, durante uma seção de desenvolvimento, ele tem que girar várias vezes. Tá. Então esse é o baby steps né. É você aos poucos, né, você cria teste, implementa, refatora, você deu pequeno passo. Você criou outro teste, deu outro passo. E aos pouquinhos você vai se aproximando daquilo que você quer. Certo? Então, explicando melhor, muita gente entende o baby step como: " eu tenho que adicionar pouca coisa de teste para o outro". E aí, às vezes a pessoa fala assim: "poxa, mas eu já sou desenvolvedor mais experiente, eu não preciso andar tão devagar". Então, na verdade, eu gosto de dizer que o baby step não significa andar devagar, adicionar pouca coisa. Eu prefiro dizer que o baby step, ele é você alternar com frequência entre criar testes e código de produção. Então se você é desenvolvedor mais experiente, você vai conseguir criar, avançar mais rápido e aí você vai, implementa mais rápido e volta para o teste de novo. O que não é baby steps, é por exemplo, sei lá, você criar ultra teste que engloba tudo o que a classe faz, depois você fica uma hora programando. Não importa o tamanho do pulo, tamanho do salto que você dá de teste para o outro, o quanto que você está incrementando na funcionalidade da classe de teste para o outro, mas sim, a frequência que você varia do teste para o código de produção. Teste, código de produção, fez mais teste, mais código de produção. Se você está fazendo isso com frequência, se você está girando esse ciclo do TDD várias vezes, então você está correto no baby steps. Certo. Então com isso, nessa aula a gente falou do ciclo do TDD, do Test Driven Development, e espero que vocês tenham entendido melhor o andamento, o papel de cada desses passos para você construir a funcionalidade no TDD. Bom, próxima aula é hands-on, a gente vai ver na prática como é que esse ciclo aí funciona. Muito obrigado Até a próxima. [MÚSICA]
