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.
Aceitando Mock Objects
Loading...
来自 Instituto Tecnológico de Aeronáutica 的课程
TDD – Desenvolvimento de Software Guiado por Testes
320 个评分
从本节课中
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.
与讲师见面
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[MÚSICA] [MÚSICA]
Meu nome é Eduardo Guerra.
Este é o curso de Desenvolvimento de Software Guiado por Testes e
hoje vamos estar falando aqui sobre aceitar Mock Objects, está.
A gente falou na aula passada que a gente pode substituir uma
dependência por Mock Object, mas para que isso aconteça,
a nossa classe precisa aceitar essas dependências, está?
Então, hoje a gente vai aprender que características a gente tem que colocar na
nossa classe, para que a nossa classe consiga aceitar essas dependências,
de aceitar os Mock Objects no lugar das dependências.
Está?
Então, nem sempre a gente consegue trocar
facilmente uma dependência por Mock Object.
Está?
Então, esse é dos motivos pelos quais a gente fala o TDD,
quando você faz o TDD, a gente deixa a classe mais desacoplada, porquê?
Esse desacoplamento vem justamente do facto de a gente criar a nossa classe para
que ela possa, para que as dependências dela possam ser trocadas pelo
mock e com isso você acaba desacoplando a classe das suas dependências.
Está?
Dê uma olhada nesse código aqui, não é.
Eu tenho ali método não é, método adiciona e dentro desse método,
eu crio uma, uma instância da classe NotificadorEstoque.
Está? Então,
como é que eu vou substituir essa dependência?
Como é que eu vou falar assim: Método cria mock no lugar dessa variável?
Está?
Então, não dá.
Não é todo o tipo de dependência, na realidade até dá, tem algumas bruxarias
aí e tal, que dá para fazer, mas realmente é muito, é bem mais complicado.
Não é a ideia ficar utilizando este tipo de coisas.
A ideia é fazer uma classe que possa aceitar esse tipo de coisa de uma forma
mais simples, está?
Então, é importante, não é, que as classes
permitam que os Mock Objects possam ser passados no lugar das dependências,
ou seja, eu tenho que, de alguma forma externamente à classe
conseguir colocar Mock Object no lugar daquela dependência, está?
Então, a classe tem que estar lá, de braços abertos aí não é,
aceitando o mock no lugar da dependência dela para poder
facilitar o nosso teste de unidade, está?
Uma das formas de fazer isso é você passar a dependência no construtor da classe.
Então, note nesse código aqui que temos aqui do lado,
que não mais o NotificadorEstoque, ele é criado dentro do método,
mas ele é recebido no construtor da classe.
Dessa forma, eu posso ir lá e passar o mock no lugar da dependência real.
Uma outra forma de fazer isso é colocar método set,
onde eu consigo injetar, colocar aquela dependência dentro da classe, não é.
Se você vai usar o construtor ou o, o set vai depender também de outras questões,
como eh, aquele, aquela dependência, ela é obrigatória?
Nesse caso, eu vou usar construtor.
Aquela dependência,
eh, eu preciso definir ela somente no momento que eu criar a classe?
Eu posso definir outras partes do ciclo de vida?
Se eu puder definir outros momentos ou puder alterar o tipo dela, então,
o método set seria mais adequado, está?
Essa questão de configurar externamente o,
a minha dependência é conhecida como
injeção de dependências, que é uma prática aí bastante conhecida aí.
A gente vai falar sobre isso daí no curso de Padrões de Projeto, está?
Mas já saiba aí que essa prática de você injetar não é?
De você colocar a dependência de uma forma externa, de forma que eh,
você tira a responsabilidade da classe de criar as suas dependências e
elas passam a ser colocadas externamente, isso aí é conhecido como Injeção de
Dependências e quando a gente faz o TDD, a gente usa muito isso daí justamente,
para poder configurar essas dependências e passar o Mock Object no lugar dela.
Bom, pode ser também que fala assim: Mas a cada invocação do
método eu posso ter tipo de NotificadorEstoque diferente, está?
Por isso que eu crio ou eu crio a partir de parâmetros que eu recebo e tal.
Nesse caso, eh, eu posso, por exemplo,
passar ele como parâmetro do meu método, está?
Eu posso até, por exemplo, fazer uma sobrecarga de métodos,
que método recebe como parâmetro e eu tenho método que não recebe,
que aí ele cria aquela instância e chama o método passando aquilo como parâmetro.
Então, todos esses artifícios a gente pode fazer para que a gente consiga eh, eh,
dentro do contexto de teste estar substituindo aquela dependência, está?
Mas, eh, eh, o que pode acontecer, você fala assim, okay.
Mas, espera aí, a dependência ali, o Notificador de Estoque é uma classe.
O Mock Object que você vai passar no lugar ali, ele é uma outra classe.
Como é que eu faço para poder colocar a classe do mock no
lugar da minha classe ali da aplicação, que é a dependência?
Então, eh, por isso a gente tem que procurar criar a dependência
da nossa classe, não como uma classe concreta mas como uma abstração,
de forma que a gente possa fazer com que a nossa dependência implemente aquela
abstração e o mock object também implemente aquela abstração.
Então, nesse caso, pegando o exemplo aí do NotificadorEstoque, eu poderia ter,
por exemplo, uma interface Notificador ou uma classe abstrata ou alguma,
algum tipo de abstração e ter essa abstração,
ao invés de ter o, a classe concreta ali.
Dessa forma, fica muito mais fácil.
Sendo que o meu mock, ele só precisa também implementar aquela
mesma abstração e, dessa forma, eu consigo pegar uma instância do mock e
colocar ali no lugar da dependência e a classe nem vai ficar
sabendo que o que está ali é o mock e não a dependência real dela.
Está?
Para a classe, a presença do mock ali é transparente.
Ela vai lidar com o mock da mesma forma que ela lida com a dependência real.
Está?
Então, usando essas práticas, a gente passa a conseguir com
que o teste possa passar o Mock Object no lugar da dependência.
Ele fala assim: olha classe aí que eu estou criando,
está aqui o objeto que você vai usar no lugar da sua dependência, está?
Por acaso, esse objeto é o mock object, está?
E, para fechar, uma coisa interessante é que fazendo tudo isso como eu
mencionei antes, você vai estar desacoplando a sua classe da dependência.
Então, de uma certa forma, você não está fazendo isso só para teste.
Você não está fazendo isso só para testar, porque você eh,
desacoplar o Mock Object, eh,
desacoplar a dependência da classe de forma a conseguir colocar
o Mock Object no lugar dela também é uma forma que o TDD
te induz a criar design mais desacoplado entre as classes.
Então, não é só para o teste.
Quando você tiver criando essas abstrações,
fazendo injeção de dependência e tal, não pensa: Que droga.
Tenho que fazer isso só por causa desse maldito teste.
Não é isso.
Você fazendo isso,
você também está criando design melhor e mais desacoplado para o seu sistema, está?
Então, não é só para o teste.
E é esse dos fatores,
pelos quais o TDD é uma técnica de desenvolvimento interessante de você usar.
Ele não só pensa a forma sistemática e segura de você ir progredindo,
mas ele também te ajuda a desacoplar as classes do seu sistema.
Certo?
Então, com isso eu espero que eu tenha conseguido mostrar
como fazer a sua classe, a classe que você
está criando numa sessão de TDD, aceitar Mock Objects para
que você possa fazer o teste e substituir as suas dependências por eles.
Certo?
Muito obrigado.
Na próxima aula, vamos falar pouquinho sobre os Mock Objects
si.
