[MÚSICA] [MÚSICA]
Esse é o curso de Orientação a Objetos com Java.
Meu nome é Eduardo Guerra.
Hoje vamos falar sobre o teste de exceções.
A gente viu aí os testes de unidades, tem feito testes nos hands on.
E não poderia faltar aqui, nessa parte de exceções a gente falar de testes.
Antes de falar, começar a mostrar como fazer, eu queria dizer que é extremamente
importante a gente testar as funcionalidades onde, digamos assim,
a coisa não corre muito bem.
Porque por exemplo se você vai abrir arquivo e tem a possibilidade
daquele arquivo não existir, faz parte da funcionalidade da
sua classe saber reagir corretamente àquele erro.
Mesmo quando a classe lança o erro para quem invoca,
você tem que saber se aquela classe está lançando aquele erro nas
situações corretas que ele deveria ser lançado.
Então, não é só testar digamos aí as situações felizes, né?
A gente tem que testar também as situações onde a execução da classe tem
que lidar aí com o caso digamos assim, fora do normal, caso excepcional.
Bom, com o JUnit,
deixa eu dar uma abaixada aqui para vocês poderem ver melhor.
Com o JUnit a gente tem aí na própria anotação que a gente conhece,
o "@test" você pode dizer que você espera que vai ocorrer uma
exceção como resultado daquele teste.
Então por exemplo, eu posso falar assim: "Olha,
nesse teste eu espero que vá acontecer 'boom exception' " e aí caso ocorra
essa 'boom exception' o teste é considerado sucesso e se
a exceção não acontecer, esse teste é falado: "Olha, aconteceu
erro porque eu esperava que essa execução gerasse a exceção 'boom exception' ".
A mesma coisa se acontecer uma outra exceção.
É importante entender que esse tipo de coisa, esse tipo de teste,
ele vai passar, ele vai rodar, vai dizer que a funcionalidade está correta,
se acontecer uma exceção não importa onde.
Não importa onde, qualquer lugar alí dentro do corpo do método,
se essa exceção acontecer então ele já considera correta a execução.
Caso você fale assim: " mas espera aí, tem "tem algumas chamadas aqui
que eu faço para preparar o meu cenário de teste que não é para esse erro acontecer,
se esse erro acontecer alí está errado." Nesses casos, onde eu vou falar assim:
"Não, eu quero que o erro aconteça mas tem que ser nesse ponto específico" aí a gente
usa uma construção diferente, eu gosto de chamar essa condição de "try fail".
O que é que você faz?
Você pega aquele ponto onde você quer que a exceção aconteça,
onde a classe vai estar funcionando corretamente se a exceção acontecer,
coloca dentro de "try" e coloca o "fail" esse "fail" é da própria,
é método da própria classe "assert".
O que é que significa?
Se o código passar por alí o teste vai falhar ou seja,
se a exceção não acontecer ele não vai pular aquele comando e vai falhar.
Esse tipo de abordagem a gente usa duas situações.
Uma quando você precisa que a exceção aconteça num ponto especifico do código,
e duas quando você não quer simplesmente verificar se a exceção acontece,
mas você quer verificar informações dentro dessa exceção.
Por exemplo, você quer ver por exemplo, na mensagem de erro tem que estar o ID,
sei lá, da pessoa envolvida ou, se eu der erro de segurança,
tem que constar na mensagem de erro o login da pessoa envolvida.
Então essa verificação das informações da exceção você pode
fazer dentro do bloco "catch".
Então, mesmo que só tem lugar que pode acontecer a exceção mas eu quero verificar
mais coisas, você usa também essa construção.
E é aquela coisa, se você não, se por exemplo,
o método alí ele joga uma exceção,
mas esse cenário de teste não é para acontecer uma exceção.
" vou botar o 'trycatch' e se no 'catch' vou dizer que deu erro".
Não, você não precisa fazer nada disso.
Você simplesmete no método de teste, você declara o ''throws'' ou seja,
você fala assim: "Olha, esse método pode jogar "essa exceção, e se essa exceção
acontecer como resultado daquela execução" aquele teste vai falhar".
Então digamos assim, você pode ficar sossegado,
fica "sussa" fica tranquilo, só declara que a exceção pode
acontecer no método, e se ela acontecer o teste vai falhar.
Você não precisa fazer mais nada se como resultado da execução daquele teste,
você não está esperando que aquela exceção seja lançada.
Então, eu vejo às vezes, principalmente quem não tem muita familiaridade com
testar classes que podem jogar exceção, o cara vai bota monte de TryCatch,
ele bota que o teste falha se der o Catch, não precisa de nada disso.
Só declara o Throws alí no método de teste e fica sossegado.
Está certo?
Então nessa aula a gente viu como testar funcionalidades que jogam exceção.
Como é que a gente faz, quando a gente cenários que a gente não espera que
a exceção aconteça, cenários que a gente espera que a exceção
aconteça e cenários que a gente quer que a exceção aconteça num ponto especifico,
ou que a gente quer verificar detalhes sobre essa exceção.
Espero que tenha ficado claro como fazer esse tipo de teste.
Vamos ver mais detalhes sobre isso aí no hands on e até à próxima aula.
Muito obrigado.
[MÚSICA]