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.
Testando Classes com Dependências
Loading...
En provenance du cours de Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
315 notes
À partir de la leçon
Semana 3
Olá! Bem-vindo à Semana 3 do curso sobre TDD! Nesta semana você aprofundará seu contato prático com casos de teste e com dependências entre classes no contexto do TDD. Ao final desta semana, você será capaz de: 1) modelar casos de teste a partir de responsabilidades para uso no ciclo TDD; 2) testar classes com dependências por meio de mock objects.
Rencontrer les enseignants
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA] Olá a todos.
O meu nome é Eduardo Guerra.
Esse é o curso de Desenvolvimento de Software Guiado por Testes.
Na aula de hoje, vamos falar sobre o teste de classes com dependência, está?
Então, a gente vai entender pouquinho porque é que a gente precisa de considerar
as dependências e como é que a gente faz quando a gente quer testar uma classe
isolada, ou seja, sem as dependências.
Está? Então, vamos falar pouquinho sobre isso.
Está?
E entender pouquinho qual, como é esse problema e o que a gente
pode fazer para testar uma classe isolada, mesmo que ela tenha dependências.
Até agora, os testes que a gente fez, os testes que
a gente viu funcionam mais ou menos, desse jeito aqui, está?
Eh, A gente tem o teste e ele interage diretamente com a classe.
Está?
Então, que acontece?
Se a gente está desenvolvendo esse teste usando o TDD, está?
O foco vai ser como que o cliente da classe interage com a interface dela,
ou seja, como que, eh, que métodos vai invocar?
Como é que vai criar objeto daquela classe?
Que parâmetros vai passar?
Qual a sequência de métodos que ele precisa chamar para chegar num determinado
resultado?
Então assim, a princípio eu estou testando eh, eh.
A única coisa que o meu teste enxerga é aquela interface ali da classe, está?
Mas e se a gente for desenvolver, por exemplo,
uma classe que interage com outra, está?
Imagina que, por exemplo, a minha classe ela faz algumas coisas,
só que ela tem uma colaboração com uma outra classe, de que ela invoca
alguns métodos para complementar aquela funcionalidade que ela faz.
Então, se a gente fizer o teste da mesma forma que a gente faz,
não é, que é o teste interagindo diretamente aqui com a classe, não é?
Só com ela, está?
A gente pode dizer que esse teste, ele não seria mais teste de unidade.
Ele seria teste de integração.
Porquê?
Porque ele está incluindo as duas classes no teste.
Está? Tanto a classe que,
no caso eu estaria desenvolvendo com o TDD, que é essa classe branquinha aqui,
quanto essa outra classezinha laranja, que eu chamei de outra classe.
Porque é que a gente pode não querer isso, está?
Por exemplo, essa classe que eu,
do qual eu dependo, ela pode por exemplo, demorar muito para executar, está?
Isso pode ser problema, porque esse cara, ele pode, por exemplo,
se ele acessa banco de dados, às vezes ele faz uma consulta que pode ser demorada.
Se eu estou rodando a minha suíte de testes inteira,
isso aí pode virar gargalo nos builds, por exemplo, da minha aplicação, está?
Às vezes até mesmo para você testar uma coisa rápida,
você tem que ficar esperando, às vezes você pode acabar com classe que tenha uma
quantidade grande de testes e aí, isso daí acabar dificultando,
não é, o andamento ali da, da sessão de desenvolvimento, está?
Essa dependência, ela pode depender de uma infraestrutura,
como arquivo ou servidor está no ar.
Por exemplo, imagina que essa dependência é uma classe que manda uma mensagem
para outro sistema, está?
Então, ela pode depender de uma série de coisas, não é,
que às vezes não são relacionadas si com o, o que você está desenvolvendo.
Por exemplo, imagina que essa dependência esteja uma classe que envia e-mail.
Isso aqui é exemplo que já aconteceu comigo, eh, eh, eh.
num projeto real.
E aí, eu tenho uma classe que eu preciso, eh, eh.
Eu tenho uma funcionalidade que, num determinado,
que determinadas situações, envia e-mail para alguém, está?
Então, eu não estou testando o envio do e-mail.
Eu quero ver se aquele e-mail é enviado naquelas situações.
Então, eu quero ver se aquela outra classe está sendo invocada.
Agora imagina para fazer o teste envolvendo aí o, o e-mail, não é.
Eu teria que ter, subir servidor,
teria que ir lá no servidor para ver se aquele e-mail foi enviado.
Isso iria dificultar muito o meu teste, não é.
Nesse caso aí, de depender de alguma coisa, da infraestrutura ali,
do ambiente onde a aplicação vai ter, está?
Esse tipo de dependência da classe é específicamente,
torna o teste muito mais difícil, está?
Outro caso, eu posso até não depender de ninguém, mas eu posso ter uma lógica
extremamente complicada, como por exemplo, sei lá: cálculos, não é,
e às vezes para pensar caso de teste que se encaixe exatamente naqueles cálculos e,
de repente, joga aquele erro daquele caso, não é.
Isso aí também pode tornar o teste muito mais complicado,
sendo que a complexidade não está na classe que eu estou desenvolvendo,
mas na dependência dela, não é.
Ou seja, porque ela acessa alguma coisa complicada,
ou porque ela demora ou porque ela tem uma lógica aí complicada, está?
Então, nesse caso o que é a gente pode fazer com a nossa sessão de TDD?
Está?
Normalmente, a sessão de TDD, ela trabalha,
normalmente não porque, pelo menos, pelo que a gente viu até agora,
a sessão de TDD trabalha nesse escudinho aqui, ali de cima não é.
Na interação do teste com a classe, ou seja, quando você está definindo os
testes, você está definindo qual é que é a interface dessa classe, está?
Só que o TDD, você pode usar ele também para você definir a interface
da dependência, ou seja, que MEC seria esse escudinho aqui de baixo,
ou seja, que métodos que a minha classe, a classe que eu estou
desenvolvendo precisa da dependência dela para fazer a sua funcionalidade.
Por exemplo, eu preciso que ela envie e-mail,
eu preciso que ela me retorne tal informação do banco de dados.
Eu preciso que ela faça tal cálculo, está?
Então, a gente pode também fazer o, o teste utilizando aí,
a gente pode fazer o TDD,
não só para definir essa interface principal da nossa classe,
mas também para definir o que é que essa classe precisa da dependência dela.
É como se eu pegasse lá as colaborações que a gente aprendeu lá no CRC não é?
E falasse assim: Olha agora eu estou colocando detalhes dessa,
dessa eh, eh, dessa colaboração, está?
Exatamente com o método com a assinatura desse método, está?
E para fazer esso tipo de teste, o que é que a gente faz?
A gente pega a dependência e
substitui ela por Mock Object, está?
Então, eh, o Mock Object ele vai ser ali, digamos assim, objeto falso que
o meu teste pode controlar e eu vou ali e coloco ele no lugar da dependência, está?
Então, o é que seria aí o Mock Object, não é?
Para dar aí uma definição, para a gente fechar aqui essa aula.
O Mock Object, ele é objeto simulado, está?
Que ele vai copiar o comportamento daquela dependência de uma forma controlada.
Então, eu posso chegar para o Mock e falar assim: Mock,
e agora você vai retornar o resultado tal.
Mock, agora você vai jogar erro.
Mock, qual foi os parâmetros que a classe que eu estou criando enviou aí para você?
Que eu quero ver se ela está invocando esse método de uma forma correta.
Mock, quantas vezes ela chamou esse método?
Porque, nesse caso de teste, não pode chamar nenhuma,
mas naquele outro tem de chamar pelo menos 3, está?
Então, o Mock Object é,
é aquele objeto simulado que a gente bota no lugar daquela dependência, está.
Eu gosto de fazer essa analogia com esses bonequinhos aqui, não é,
que chamam o Crash Dummy não é,
que é aqueles bonequinhos que a gente coloca dentro do carro, não é?
Porquê?
Porque se a gente for parar para pensar,
não é viável você ir lá e botar uma pessoa de verdade dentro do carro para você dar
uma cacetada com o carro na parede e ver o que acontece com aquela pessoa, está?
Então, por causa disso, a gente coloca esses dummies,
não é, a gente coloca esses bonecos que eles inclusive vão ter uma forma muito
melhor do que a pessoa até para medir a força do impacto, não é,
os locais ali onde teve uma maior eh, maior esforço e tal.
Então, eh, eh,
é a mesma coisa do que a nossa dependência que é difícil de testar, não é?
É cálculo, ela demora, ela depende de infraestrutura,
ela tem uma lógica própria ali que vai complicar o meu teste.
Então, bota o Mock ali.
É como se fosse esse bonequinho,
ele vai te ajudar a verificar como é essa interação entre as classes e você
vai conseguir controlar ele para simular os cenários que você precisa, está?
Então, nessa aula, o objetivo foi falar pouco mais
sobre o teste dessas classes com dependência, está?
Eu queria apresentar para vocês o que são os Mock Object,
mas fique tranquilo que nas próximas aulas vamos entrar
mais detalhes sobre os Mock Objects, como criar eles?
Como eles funcionam?
Como colocar eles dentro da classe?
Está certo?
Muito obrigado por assistir.
Vejo vocês na próxima aula.
[MÚSICA] [MÚSICA]
Explorer notre catalogue
Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.
Coursera propose un accès universel à la meilleure formation au monde,
en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.
© 2018 Coursera Inc. Tous droits réservés.
