Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, com método e organização graças às boas práticas e princípios exercitados no curso anterior; mas você talvez não se sinta ainda confortável em projetar programas usando técnicas ágeis, como o desenvolvimento guiado por testes (TDD). O objetivo deste curso é expor você aos princípios e práticas de desenvolvimento guiado por testes, tanto para modelar quanto para desenvolver aplicações e componentes de software, sem abandonar os conceitos e princípios de orientação a objetos aprendidos no curso anterior. De fato, pregamos que tais conceitos e princípios fortalecem o emprego do TDD no desenvolvimento ágil de software com mais qualidade. Este curso terá um grande foco em atividades hands-on, permitindo a você captar todos os aspectos práticos da técnica e facilitar a sua aplicação quando estiver projetando e desenvolvendo software de maneira ágil nos próximos cursos. Os conceitos de desenvolvimento de software com Java apresentados neste curso incluem o seguinte: revisão de testes de unidade; automação de testes; desenvolvimento guiado por testes; ciclo do TDD; refatoração de código de produção; ciclo de refatoração; uso de objetos stubs e mocks; boas práticas no TDD; modelagem de software por meio do TDD. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar, agora usando o TDD, versões modificadas e estendidas do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Ciclo do TDD
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
330 classificações
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
Instituto Tecnológico de Aeronáutica
330 classificações
Na lição
Semana 1
Olá, bem-vindo ao Curso 2 – Desenvolvimento de Software Guiado por Testes. Neste módulo você fará contato com os conceitos básicos de TDD. Ao final desta semana, você será capaz de: 1) entender como funciona o TDD e, principalmente, que o TDD é uma técnica poderosa de projeto e desenvolvimento de software; 2) será capaz de entender o papel fundamental da Refatoracão dentro do ciclo do TDD, permitindo a você alcançar um código de mais qualidade passo a passo e continuamente!
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2019 Coursera Inc. Todos os direitos reservados.
