[No Audio]
So in this video we're going to explore
what test failure looks like in the IDE.
And that's when a test fails.
So as we saw in the previous video, when
a test passes and is successful, we get green,
but we can also have red as well. So for
example here, if I simulate an exception being thrown
[No Audio]
and then rerun,
[No Audio]
you can see here we now have red, and the test failed.
It says the test failed, 1 of 1 test failed. And
the reason being, is that we have this RuntimeException
here and this would be a full stack trace
which would enable you to pinpoint the exact point
where the unit test failure occurred and the sequence
of method calls which led up to that test failure.
Now the reason for this is because we didn't
set this test up to expect a RuntimeException.
So JUnit takes the reasonably fair approach
of viewing an exception which occurs during
its execution as a test failure.
However, if you had a test in which you specifically
wanted to ensure that an exception must run,
for example supposing, you're testing some validation
and you're testing the validation routine with
bad input, then because you're testing the
validation routine with bad input, you
would expect that the class that you're testing
would throw some kind of validation exception
back out to the user.
And so in that case you'd want to tell
JUnit they are actually expecting an exception.
And you can do this, by using an
addon to @Test or rather an extra parameter
to the test annotation which is expected.
So if you put expected equals under the class,
[No Audio]
then this signifies to JUnit that during that test
it's expecting that it's going to get a runtime
exception and that's a good thing and therefore it will
pass the test. So if I ruin this now
[No Audio]
you can see here the test passes once again.
Of course this throw new RuntimeException is
just contrived and we will never put this
snippet of code inside a unit test.
Rather this exception will be thrown
out from the clash of testing.
But nevertheless I wanted to show you that just to
tell you about the expected annotation parameter to
test. Since that's the way that we can actually
evaluate that we're getting back the exceptions
that we expect if the API we're testing is designed
to them back under that particular test case.
But anyway, now you know about test failure
and exceptions in Junit, we should be in
a good position now to move forward.