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.
Hands-on: Primeira Classe com TDD - Parte 3
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
312 ratings
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]
Chegamos então na terceira parte aqui do nosso hands on para desenvolver uma pilha.
A gente já tem três testes aqui: a pilha vazia, empilhar
elemento e empilhar e desempilhar elementos.
Agora vamos ver aqui como que a gente trata aí a pilha cheia e quando
eu tento colocar alguma coisa numa pilha que já está cheia ou
quando eu tento remover alguma coisa de uma pilha que está vazia, está?
É. bom, o que é que eu vou fazer aqui?
Eu vou eh, a primeira coisa que eu vou querer fazer vai ser refaturar
para adicionar aqui o método before.
A gente no curso aí de Orientação a Objeto, a gente viu aí,
o método before do JUnit.
Então, eu vou dar uma refaturada nos meus testes que eu
vou chamar aqui, opa, de inicializaPilha.
É, então,
eu vou vir aqui, vou importar o before do Junit,
eu vou copiar, eh,
a pilha aqui para a minha classe e vou colocar.
Então, assim, reparem que a cada teste não é,
ele vai executar o before e vai criar uma nova instância,
uma instância zerada ali de pilha, está?
O que eu quero aqui?
Eu quero poder passar o tamanho da pilha no construtor.
Então, eu, por exemplo, colocaria ali 10, não é?
Então, note que eu sempre mudo o teste antes de mudar a classe, está?
Então, eu vou vir aqui, vou criar esse construtor e eh,
vou inicializar não é,
o array aqui nesse construtor, está?
E aqui, obviamente vai receber o, vou chamar o parâmetro aqui
de máximo e eu vou passar aqui o máximo como parâmetro ali para o array.
Aqui, eu posso tirar isso.
Bom, será que, bom, agora eu preciso tirar aqui do,
as pilhas aqui do teste, não é?
E aí, eu vou rodar aqui para ver se o meu teste continua
funcionando depois dessa mudança aqui.
Okay, funcionou, eu posso seguir frente.
Eu vou eh, criar mais teste que eu vou chamar
de eh, removeDaPilhaVazia,
está?
Então, aqui eu simplesmente vou vir e vou chamar desempilha,
aqui, está?
E aí, o o que é que vai acontecer?
Eu vou criar, vou vir aqui no meu teste eh,
e vou dizer que o expected
é Pilha
VaziaException.
Vou dizer que eu espero que aconteça uma pilhaVaziaException, está?
Essa, essa classe não existe.
Então, eu vou vir aqui pedir para criar a classe, eu vou criar a princípio,
como uma Run Time Exception, porque eu não quero que o pessoal precise ficar
verificando isso toda a vez que vai desempilhar alguma coisa.
Então, eu vou vir aqui, vou dar o finish está, vou salvar.
Eu tenho que criar, pelo menos, construtor.
O que é que ele tá reclamando aqui?
Eh, ele está dizendo que tem
construtor que eu tenho que criar eh,
eu vou criar aqui então, public.
Deixa eu salvar aqui para ver se o eclipse me ajuda e
cria para mim esse construtor aqui.
Não, não tá querendo criar.
Vou ter que criar na mão mesmo.
Vamos lá, public PilhaVaziaException eh,
vamos passar aqui uma mensagem e aí,
eu vou chamar aqui, simplesmente, o super com essa mensagem, não é?
Eu tenho Runtime exception e tem essa.
Está, ele está só Runtime, por isso que está,
por isso o problema.
Está, agora foi.
Por isso é que o Eclipse não estava me ajudando, não é,
não boto o nome da classe certa o que é que eu quero?
Então, agora o meu teste aqui tá compilando está,
porque ele reconhece só que eu vou rodar ele e ele não está, não é, ele tá dando
uma array out of bounds exception, mas não é a minha Pilha Vazia Exception.
Então, eu vou ver aqui na Pilha.
Isso aqui acontece no método desempilha, não é?
Então, eu vou verificar não é, se a quantidade nem preciso não é?
Se a pilha está vazia, eu tenho método que verifica isso,
se está vazia: throw new
PilhaVaziaException, eh,
aí vou colocar aqui "Não
é possível desempilhar".
Muito bom.
Eh, vamos, vamos rodar aqui e ver se agora, agora funcionou.
Muito bem, muito bom.
Está então, isso aqui a gente vê exemplo não é,
como é que a gente pode também criar testes para a situação de erro, está?
Eu vou criar outro teste aqui que vai ser o meu,
eh, Pilha CheiaException, está?
Eh, então, eu vou chamar esse teste de eh,
adicionaNaPilha Cheia.
Então, o que é que ele vai fazer?
No caso aqui, a minha pilha não é, toda que eu estou criando aqui ela,
ela é de tamanho 10.
Então, eu vou fazer for aqui Vamos lá: for
int i igual a 0, opa,
e menor do que 10 i mais, mais, está?
Aqui, eu vou empilhar.
Eh, então eu vou chamar aqui de p.empilha,
vou chamar aqui de
elemento e vou somar o i ali.
E aqui não é, ali eu estou colocando dez elementos,
a princípio é pra funcionar, não é?
Aqui, eu vou chamar p.empilha e vou passar
aqui como parâmetro boom não é, que é para a pilha estourar.
Então, ele vai dar o erro aqui no boom.
Então, eu vou salvar, vou vir
aqui e vou pedir ajuda pro Eclipse para criar essa classe.
Vamos ver se agora eu coloco aqui a superclasse direito não é,
que eu quero é o Runtime Exception.
Aqui não é só, não é o Runtime, está?
Já vou marcar aqui os construtores da superclasse e ele criou monte aqui.
Para mim, interessa só esse aqui, que ele passa a mensagem.
O resto aqui eu vou apagar.
Então, eu salvo agora o meu,
meu teste ele já está, eh, já está compilando não é?
Eu posso rodar e ver ele falhar.
Também ele dá array index out of bounds exception, que não é o que eu quero.
Eu quero uma Pilha Cheia Exception.
Então, eu vou vir aqui não é e vou no método empilha,
eu vou verificar não é?
Se a quantidade foi igual ao tamanho máximo.
Como é que eu sei o tamanho máximo?
Acho que eu posso pegar o tamanho ali do array elemento não é?
Ponto length.
Então, ele vai eh,
eh, jogar não é throw
new Pilha CheiaException.
A mensagem ali "Não é possível empilhar mais elementos".
Muito bom!
Eu vou salvar aqui e vou executar.
Olha que beleza!
Tá aí a minha pilha implementada.
Tá.
Antes de terminar essa aula eu queria chamar
a atenção de vocês para pequeno detalhe.
Tá, esse pequeno detalhe é o seguinte: esse teste aqui,
adicionaNaPilhaCheia, ele não é bom teste.
Como que a gente sabe que ele não é bom teste?
Porque eu posso de repente introduzir
defeito na minha classe e esse teste não vai pegar esse defeito.
Tá? Então,
pense aí: Que problema é esse nesse teste?
O problema desse
teste é que o erro, esse PilhaCheiaException,
ele deveria tá verificando se esse erro acontece no "boom".
E se esse erro acontecer qualquer outro "empilha" dentro desse loop aqui, o teste,
ele vai dar como se o comportamento estivesse correto, e não está.
Como que a gente verifica isso?
A gente pode inserir bug aqui no software, né, por exemplo,
ó: Eu quero que ele dê problema aqui, ó,
sei lá, -3 aqui no tamanho, né, ele vai dar o problema muito
antes; ele vai jogar a exceção muito antes de a pilha realmente estar cheia, né.
E se eu rodar o meu teste ele vai passar.
Tá, ou seja, o meu teste não tá pegando esse bug.
Que que eu tenho que fazer aqui?
Ao invés de usar o...
quando...
no caso de cima, eu só tenho uma linha de código, né?
É o único lugar que pode dar o problema.
Então não tem problema eu usar o expected.
Quando eu tenho lugar específico que pode dar o problema, tá,
o ideal é eu fazer aquele try/catch, né.
Eu vou vir aqui, ó, é, vou dar "Surround with",
"Try/catch block", aqui,
depois do try, eu vou colocar "fail()",
né, ou seja, se ele não deu a exceção,
ele vai dar o problema e é...
Aqui, ó, eu vou verificar se ele dá o Pilha...
...CheiaException.
Certo?
Então, vamos ver aqui, ó,
eu gosto de chamar essa construção aqui de "try/fail".
É quando você verifica a exceção dentro do "try".
Vamos rodar agora, ó, agora ele tá pegando, ó.
Ele tá dando PilhaCheiaException, se eu clicar aqui, ó,
ele tá dando PilhaCheiaException aqui no meu "empilha",
tá, o que não é o comportamento que eu quero, não é o comportamento esperado, tá.
Então eu vou vir aqui, ó, vou corrigir aqui o código e vou mostrar aqui que com o
código correto, e somente com ele correto, o teste vai funcionar.
Agora sim!
Então com isso a gente termina esse hands-on da pilha e eu queria deixar, né,
com essa última questão aí, essa lição de que não basta, né,
a gente criar o teste e a classe passar no teste.
O teste tem que realmente tá verificando o comportamento que a gente quer pra classe.
Certo?
Muito obrigado, espero que com essa prática,
com esse hands-on tenha ficado mais claro como que funciona o TDD.
Se a...
Eu sei que é difícil no começo, que você ainda tá começando, mas teremos
outros hands-on onde vamos explorar ainda mais esses conceitos do TDD.
Muito obrigado, até a próxima aula.
[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.
© 2018 Coursera Inc. Todos os direitos reservados.
