[No Audio]
In this video, we're going to explore
JUnit's @Before annotation, which lets us
keep our unit test setup code dry.
That stands for don't repeat yourself, in other
words, we don't have the duplication of a setup
method, and we'll see how to do that right now.
So let's think back now and look at the unit test
and assess the kind of unit test that it is.
So thinking about that test we've written, because
that's obviously a very simple test and we don't
usually have methods which are so simple,
they're just a simple function which is defined
as a static method taking two integers.
Normally we have state on objects.
So let's rework this production class just
for the sake of our example. And let's
assume that it isn't a static method. In other words,
we have to create some instance of Calculator first.
[No Audio]
It's like we go back to here.
We can see this is highlighted in red.
This is now a compilation error.
It can't reference from a static context.
So we could fix it by doing this new Calculator.
However, that violates our Arrange/ Act/ Assert
sections because the test object, the object which
we're testing is the system on the test that
needs to go into the arrange phase.
So let's just put it in the arrange phase instead,
[No Audio]
just to keep things nice and consistent
with the methodology.
So now just rerun that, just to make sure
everything still works, which it does. That's fine.
And let's suppose we had another test.
[No Audio]
Just copy this one for now,
[No Audio]
just click testAdd 0.
So a test when we want to, see
what happens when we add 0 to something.
Not the most interesting test, but we
don't care about that for now.
We just care about learning about how JUnit works.
So, this should be the answer here,
lets just make this a bit more descriptive.
testAddPositiveNumbers,
[No Audio]
testAddZeroToPositive
[No Audio]
and rerun this now, if I do run CalculatorTest,
[No Audio]
you'll now see there are two
[No Audio]
tests which have been run here.
So now there are two test cases on this
test class, and every time you click a test
method, any output related to that test method would
appear here, or any test failure.
For example, assertions not passing that kind
of thing would also appear here.
If had a full set of test methods, say 20
test methods here and say like three of them failed,
then you'll be able to click on the individual failures
and see what happened in the right hand pane here.
But what I want to show you now and
highlight is the fact that we have some duplication.
[No Audio]
So here you can see when we're arranging, either
of these tests, we do the instantiation of the
system of the test in the method each time.
So we can refactor this slightly and
we can use another one of Junits
annotations, which is called @Before.
So if I now use @Before again from org.junit
[No Audio]
and have a method public void setup.
This will enable me to put this setup card
[No Audio]
in that method,
[No Audio]
delete this one
[No Audio]
and this method will be executed
before each test, just set up the so called test
fixture for the test and that basically means the set
of objects or the state if you like of the
test class before each individual test is run.
Now you can see here this is in red, it's
calc in here and here and that's because we need
to actually push this state
[No Audio]
business system and the test that we're going to be
running a test for, into the test class itselfs
so we give it a private member
variable here, which we can call calc.
And now if we rerun
all the tests again they should be green,
[No Audio]
so this is nice this basically means that
we've got, commonality to set up our test fixture in
this setup method, so it's not duplicated across all of
the tests and we have individual arrange sections
which are very specific to each test so this is going
into being a very nice kind of well structured test.
Now it doesn't look like much at this stage because
this is a very trivial example. But if you imagine
you had a class which maybe takes a few different
collaborators a few different objects which it needs to
interact with, and maybe they need to be set up in
a specific way which is common across all these tests.
Then you can imagine it, this this method would be
quite useful. And that's how we can keep set up test
code dry using the @Before adaptation.