[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]
