ok so we can further optimize this
method a little bit more if we're
actually expecting an exception to be
thrown
we'd have to modify the annotation line
as you saw on line 36 we can also remove
these assert equals as well because
we're not testing for equality in this
case we just testing to see whether the
exception is thrown in the case of
invalid input i'm going to remove that
remove that completely and the test can
literally just be that one line there
and in fact we can even remove the local
variable because we don't need that
anymore as well we're really just purely
just testing in this particular test to
see whether that exception is thrown
given that the parameters are invalid
for the amount of money to be
withdrawn from an ATM
let's just run that you can see that the
test is still passing there working fine
now not that annotations were only introduced
in j unit 4 when using earlier units or
versions of j unit what would have to do
is surround the code that would throw an
exception with a try-catch block and we
wouldn't do anything in the catch block
remember that if you don't assert
anything the test will pass so in that
case we do the following working with an
early version just want to show you this
because you may come across the code
along those lines I want to do first is
comment this bit out here for now and
we're going to write the extra code
assuming we're in the scenario an older
version of j unit we need to introduce a try
...
....
...
...so we'll do it that way we
run it we should see that we get the same
result you can see we get the same tests test
results that all our tests pass because
we've caught the exception in this case
because we're expecting it and we don't
need to do any processing the method
because we caught the exception but the
other thing i want to show you what we
should really be doing here to be more
specific
we should really have a fail here as
well
and the fail....
...I'm gonna
run the tests and just to confirm that
this code will work will put a true
their run it we get that fail you
should've thrown an illegal argument
exception
that's how we would have had to do it in
the past it's a lot easier than that
these days i'm just going to put the
code back to how it was
so again this is the j unit 4 way of
doing it which is a heck of a lot easier
I guess to be correct
we also put a fail here as well
run the test again and again it passes
because the exception is thrown and this
code is actually bypassed ok alright
so the final j unit topic that I want
to cover is parameterize tests so we
want every test to start fresh that can
result in a lot of repetitive code for
example let's suppose we want to try
depositing five different amounts and
verifying the resulting balance we could
write five different test cases but we
can also write a parameterised test now
we have to use a class annotation to run
parameterize test so let's create a new
task a new test class open the
project pane new class will call this
one bank account
test parameterised like so and let's
start by creating an instance variable
...
okay what we need to do now though is tell
junit this isn't a normal test class we want
to tell it that we want to use it to run
a parameterised test so we need to use
the at run with annotation on the class
definition itself come up here to the top
we're going to put....
...
...and as a confirmation if
you got this right you should see
these two little green arrows in the
gutter to the left of the class
definition
ok so let's so let's suppose we're going
to call the deposit method with branch
equal to true and a number of values so
five different values what we have to
do is tell j unit that these are the
parameters we want to use we're going to
do so by adding a static method
annotated with the at parameters
annotation and that method is so we need
to return a collection so we're going to
come down below the setup method we're
gonna put...
....
ok so what have we done here well each row as you can see
on line 26 to 30 is the set of parameters
we want to test followed by the expected
value now when we run the parameterize
test junit will create a new
instance of the bank account test
parameterised class for each set of test
data and I will use the class constructor
just too set instance variables to
the values specified now we need to do
two things add instance variables for
the deposit amount the branch value and
the expected value and we also need to
add a constructor that accepts the
values and sets the instance variables
so let's go ahead and do that i'm going
to below here below the bank account
going to type....
...
created that constructor let's go back to
the bank account test class like so and
what we want to do is grab a copy of the
deposit test so just copy that
now back to the bank account test
parameterised java file and will paste
that method in there accept that import
and we just need to modify this to use
the instance variables rather than hard
coding the values so i'm going to change
this...
...
...so the 3
values that coming from here which
ultimately are being created from our
collection objects for the test
conditions method what we can do now is
we can actually run the test by clicking
on this green arrow to the left of
the get deposit lets actually just change
that will just call the method deposit
for simplicity and we'll run it run
deposit and you can see that ran various
tests and we've actually got some output
here to the left showing the
various tests in fact that was run 5 times
but this third one is interesting and you
see a deposit 2 and the problem with
that is we've got this expected value 13
25.14 but the actual values 1325.1
39999 and this is where the
Delta option actually comes in terms of
the tests that mark fail in my case you
can see was the third one but you might
find that the fourth one actually fails
here it does really depends on your system
as to which one will fail or which one could
fail so we need to do now is just change
this Delta parameter to take that into
account
I can change that to make that .01
run the test method again
run deposit we can see that this time
with actually allowed the delta to be .01
which is enough now to actually
cover for the fact that it was so close
enough dealing with the double precision
that is part of double primitive type so
in most cases you won't need to do that
but you can see where this delta
optional
comes in to play if you do need to do
that when you're testing double
primitive type
alright so that's how we run a bunch of
tests on the same method as you can see
there you saw that there was a bit of
work to set it all up but then it does
cut down on the amount of test code that
we have to maintain and just to confirm
if you look over to the left hand side
here
intellij created a new run configuration
for the class so if you want to run this
again now we've got this bank account
test parameterised deposit that we can
run at any time and over here to the
left the five tests showing having run
and the test pane also labels each test
using its index in the collection
alright so now that you've seen how j
unit gets the test values and passes
them to the test method hoping it now
you can understand why we have to create
a class for each parameterised test that
we want to run alright so that
concludes our tour of j unit
obviously we can't go through every
detail of the junit as its quite
extensive and there's a lot more that
could be covered now there's certainly
more that you can do with the framework
but you now have the basics and coupled with
you spending some time looking at
the documentation and playing
around with it i'm sure you'll get a lot
out of it in the next video we're going
to start working on a J unit challenge
i'll see you in the next video