[MÚSICA] [MÚSICA] Olá a todos, o meu nome é Eduardo Guerra e estamos no curso de Desenvolvimento de Software Guiado por Testes. Hoje vamos falar sobre os princípios do TDD, está? A ideia é assim, falar pouco sobre o que tem por trás ali do TDD, porque é que ele funciona, quais são aqueles princípios ali, o que é que é importante a gente entender, do porquê o TDD, é uma técnica, entender os seus benefícios, quais os valores que tem ali por trás do TDD, certo? Então, agora que vocês já viram pouquinho do TDD na prática, a gente vai falar pouquinho para vocês entenderem melhor como isso daí funciona. Bom, o primeiro princípio do TDD, é que ele se baseia no facto de que o feedback rápido é importante para o aprendizado. Bom, vou pegar exemplo aqui que talvez todos vocês aí já tenham passado dia. Imagina aquele professor que você vai, faz, você estuda, faz a prova e aí ele vai e só entrega a prova, corrigida, 2 meses depois. E aí você pega, você viu que acertou algumas coisas, que errou e aí você já não consegue mais julgar direito, você não sabe porquê é que foi mesmo que eu fiz esse exercício desse jeito e aí aquele feedback às vezes já não tem muito valor para você. Por outro lado, aquele professor que pega e entrega a prova rápido, você fez a prova e 2 dias depois ele entregou a prova, a matéria está fresca na sua cabeça, você sabe porque você usou aquela solução e aí se você errar alguma coisa, você vai ali olhar para aquela prova de uma forma muito mais crítica, você vai aprender com aquilo. Então, o feedback rápido ele é muito importante para que você consiga lembrar da, do porquê que você fez aquilo, do porque é que deu errado. Uma coisa que eu vejo, às vezes o cara vai lá, está fazendo software e às vezes é software que tem várias camadas, tem vários pedaços e o cara vai cria 'iii' de dados, cria lógica de negócios, cria o cara ali que processo arquivo e tal, e aí demora uns 2 ou 3 dias para o cara conseguir realmente rodar e testar aquele software e aí com isso ele perde o feedback, aí ele roda, dá uma coisa errada e ele fala " nossa, o erro está nessa classe, mas eu nem lembro porque é que eu fiz assim, eu nem lembro direito dessa classe." No TDD o feedback é imediato, você criou o teste, se você rodar e não passar, você já vê o porque é que aquele teste não está passando. Se você fez uma modificação no código, seja por uma refaturação ou porque você está adicionando mais funcionalidade e de repente quebra teste anterior e tal, você vai olhar e vai falar assim: " é por isso que deu problema!". Você entende, o seu feedback é na hora. Então, isso faz com que você entenda o porquê que aquele erro aconteceu e evite ele no futuro. Então, o aprendizado, quando o feedback é rápido, ele é muito mais depressa. Você vai ver que fazendo o TDD, você rapidamente vai conseguir não errar mais aquelas mesmas coisas que você errava, você vai aprender muito mais rápido, você vai andar para a frente com mais segurança. Uma outra questão do TDD que eu já falei, vou vir aqui para o Espaço, aqui para contar uma historinha para vocês, certo? Que é o TDD ele é ele usa esse princípio da solução mais simples que funciona. Desculpe que eu estou meio tonto aqui de estar aqui no Espaço. Mas ele usa, eu vou contar uma história para vocês, certo? É uma história fictícia, mas eu acho que ilustra bem, que dizem que o pessoal vende aí na internet a tal da caneta da Nasa, você pode escrever de ponta à cabeça a gravidade zero que você consegue escrever. E aí gastou milhões para desenvolver essa caneta, a tecnologia dessa caneta, e aí foram os russos lá e levaram lápis para o Espaço. Essa história é meio que uma lenda urbana mas mostra que muitas vezes a gente, a gente se prende ao facto de que, tem que ser uma caneta, e aí busca, vamos fazer a caneta que escreve no Espaço. E esquece-se que ás vezes o meu problema é escrever no Espaço, e às vezes existem outras soluções que não são caneta. Então o TDD, tem como seu princípio de buscar a solução mais simples que funciona. Talvez você fale assim: mas nem sempre vais ser uma solução simples que vai funcionar. Sim, mas é a que, talvez seja a mais simples que funciona para aqueles testes, e às vezes a mais simples para aqueles testes é a complicada. A questão é que normalmente as soluções que precisam de ser complicadas elas podem ser muito mais complicadas se você não prezar pela simplicidade, está? O TDD ele tem essa ideia do design evolutivo. E seguindo as necessidades da aplicação. Erro muito comum que a gente vê no design de software, é o chamado overdesign, ou seja quando o cara faz projeto muito maior ou muito mais complicado do que o necessário. Então, uma coisa que já me falaram que é muito sábia, é aquela coisa, quando você tenta prever como vai ser eu já vi muita gente: mas pode ser que mude isso, pode ser que mude aquilo, então, por isso é que estou colocando isso, por isso é que estou colocando aqui no outro. Então, o que acontece? Quando você tentar prever mudança, a mim pelo menos, a minha experiência mostra que muitas vezes aquela mudança não acontece e às vezes você acaba gastando tempo, gastando esforço da sua equipa para desenvolver uma solução que não não vai ser usada e muitas vezes quando aquilo acontece, acontece de uma forma, de jeito diferente do que você tinha previsto e mesmo assim aquela solução que você tinha bolado não vai poder ser utilizada. Então, o TDD tem essa questão, a questão da solução mais simples, faz com que à medida que você for criando testes, o design vai evoluindo junto com as suas necessidades e o facto de a refaturação ser passo importante do TDD, e a cada ciclo você olha para a refaturação, isso significa que a cada ciclo do TDD uma questão de minutos, ou às vezes nem isso, dependendo da velocidade do ciclo, você está olhando para a sua classe repensando o design dela. Então, se algum ponto você vê que uma outra solução vai ser melhor, vai ser mais eficiente, você vai e refatora o seu código para ela. Então, o seu código, ele não é nem mais nem menos do que aquilo que a sua aplicação precisa naquele momento, você não vai fazer uma solução para teste, digamos assim, que ainda não chegou, certo? Nem você vai ficar com design que já está ultrapassado para as necessidade correntes da sua solução. O design ele vai andando junto com o código, a estrutura da sua aplicação, das suas classes, vai andando junto com o código. Então, você nem vai fazer algo complicado demais, nem simples demais. Você vai na medida exata. Porquê? Porque você está evoluindo e está pensando nisso toda a hora. Bom, temos os testes, os testes acabam sendo aí uma herança boa que o TDD deixa para a gente. Então, os testes eles dão uma segurança bem grande, para que a gente possa saber quando alguma coisa deu errada e isso é muito bom. Eu vejo que muita gente às vezes fica lambendo o código, ou seja: será que eu errei? Será que está certo? Aí o cara vai olha o código, 1, 2, 3, 10, 20 vezes conferindo para ver se está certo e cada mudancinha que faz, principalmente se for pedaço de código importante, o cara vai e olha, olha e olha. Enquanto que com os testes ele simplesmente pode chegar lá, executar os testes e ver se falhou ou não, se quebrou ou não alguma funcionalidade que já existia. Se você não está seguro com os seus testes, você pode ir lá e criar mais testes, criar testes de novos cenários para que você possa ter segurança e isso ajudar nas mudanças, principalmente na refatoração, muitas vezes a gente não vai lá e não melhora uma classe porque a gente tem medo que ao fazer isso a gente quebrar aquela classe, a gente inserir bug ali sem querer, e com os testes a gente vai saber se aparecer bug. Então, você ter os testes, é uma segurança para você poder fazer modificações nos seu código. Isso daí é uma coisa bem positiva que é dos princípios aí do TDD. Documentação, eu já vi muita documentação desatualizada, certo, De código, o cara pega lá: deixa eu ver a documentação, aí pega lá vai olhar a classe e está completamente diferente. está? A documentação é gerada pelo TDD nos próprios testes, o que é que são os testes senão vários exemplos de como aquela classe funciona e como ela tem que ser usada. Tem caso aí, não aconteceu comigo, colega meu trabalha numa empresa e ele precisava gerar componente, na Web para uma outra empresa consumir. E aí o que é que ele fez? Ele pegou, criou o componente, criou os testes e criou uma documentação de como utilizar, colocou os testes e a documentação para download. O cara foi, implementou, usou, funcionou direitinho e aí quando ele foi olhar as estatísticas do servidor dele, ele viu que o cara tinha baixado o teste mas nem baixou a documentação. Então, é aquela coisa: o que é que você vai querer, você quer saber como usar uma classe, o que é que você vai buscar lá no Google, você vai procurar exemplo de alguém usando essa classe, ou você vai lá e vai querer ver uma descrição da classe? Normalmente a gente quer logo exemplo para a gente ver e o teste nada mais é do que isso, não só o exemplo como através das asserções ele já diz como é que aquilo funciona. E a grande vantagem dos testes é que como eles estão rodando, eles estão 100 por cento atualizados com o que a classe está fazendo, então, os testes, eles não só servem para a questão da segurança, de você não introduzir erros de forma acidental no código, mas também como uma documentação, que você pode consultar eles e uma documentação sempre atualizada. Outra coisa, todo código é culpado a não ser que ele se prove inocente, o que é que significa isso? Eu vejo muita gente: tem Bug no seu código, aí sai o cara: me prova, me mostra. Ou seja, o ônus de provar que tem Bug é do cliente, eu acho que deveria ser o contrário. O código, ele tem Bug a não ser que você prove que aquilo está funcionando, que ele se prove inocente. Certo? Então o teste é isso daí, para você entregar o código, você tem que provar que ele está funcionando e você faz isso através do teste, está? Pensa nisso, vê se não faz sentido que é quem está entregando que tem que provar que aquilo está funcionando e não quem está recebendo que tem que provar que alguma coisa não está funcionando ali no código. Então lembre-se disso, lembre-se dessa frase: Todo código é culpado até que se prove inocente. [SEM ÁUDIO] E para terminar, é mais divertido fazer os testes antes, do que você criar o código e fazer os testes depois. Por que é mais divertido fazer os testes antes? Acho que vocês vão experimentar aí, quem fez o curso de Orientação a Objetos, criou testes lá com JUnit, talvez tenha criado depois, se não conhecia o TDD, e você vai ver agora, que quando você está criando os testes agora, é muito mais interessante, por quê? Porque no TDD, quando você cria teste, você está criando muito mais do que teste, você está especificando a classe que você vai criar, você está especificando a interface, você está definindo qual vai ser o comportamento dela. Então você criar o teste no TDD é uma intimidade muito mais interessante que exige muito mais da sua cabeça, que você tem que pensar muito mais, do que simplesmente você ir lá e criar teste para uma coisa que já está funcionando. Então é muito mais divertido, quero escutar aí no fórum aí nos comentários, se vocês, se não é muito mais legal criar os testes antes do código do que criar depois. Está certo? Bom. nessa aula, a gente falou alguns dos princípios do TDD, questões que estão ali, digamos assim, no âmago ali do TDD, do porquê que ele funciona e por que é que é uma técnica que está sendo cada vez mais adotada. Não só para você criar lá os seus códigos com TDD e constatar que aquilo ali está funcionando, mas para você entender o porquê de ter esses benefícios aí que ele traz. Está certo? Muito obrigado, até a próxima aula!
