Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
JUnit tests have several hooks that allow you to run before and after each test method. Let's explore!
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Awesome.
0:00
Thanks for cleaning up that test for us.
0:00
We are definitely starting
to repeat ourselves.
0:02
And even in test land,
we want to make sure that we keep dry.
0:05
In order to fully understand the way to
fix this don't repeat yourself problem.
0:10
I first want to make sure that we
understand more or less what has happened.
0:15
First of all,
0:19
these classes that contain the methods
marked with Test are called fixtures.
0:20
They have some hidden powers that
we haven't talked about yet.
0:25
When you kick off the Test runner,
what happens is that each method
0:28
that is annotated with the @Test
annotation is gathered.
0:31
[SOUND] The runner then
loops through each test.
0:34
And for each test that it instantiates,
it creates a brand new object and
0:37
runs that single method.
0:41
There is no guaranteed
order to those tests.
0:43
So because each class gets it's
own instance you can actually add
0:45
fields to the class definition and
each of the methods can access those.
0:49
You might think you add a constructor to
initialize these but that isn't the case.
0:54
There is a special type of annotation
called a fixture annotation that
0:59
helps us out.
1:02
It's named @Before.
1:04
We use it to annotate methods
that then set things up.
1:06
So what do you say we
stop repeating ourselves?
1:10
What do you say we stop
repeating ourselves?
1:12
What do you say we stop
repeating ourselves?
1:14
See how annoying that is.
1:17
Let's stop doing that.
1:18
Okay, so let's take care of
that repeating perpetrator.
1:20
So just looking at this I can see
the problem that we're creating is
1:25
each of these tests is instantiating
a new creditor object, right.
1:28
This one is, that one is, this one is,
1:33
we're doing the exact same
thing in each method.
1:35
So let's add a new before method.
1:37
Now, historically when these
were created in the past,
1:39
they needed to be called set up.
1:43
It was a specific naming convention, so
like when you set up before each method.
1:44
So if we go to Generate, so
again it's Code, Generate and we're
1:49
going to do the SetUp Method, which is
gonna give us one of those before methods.
1:54
Okay.
2:00
And here we are going to
get a new creditor object.
2:01
And of course it doesn't know
what we're talking about.
2:08
So let's go ahead and we will create
a field called Creditor and that's fine.
2:09
All right, so now the test
instance has access to a creditor.
2:17
So now we can get rid of in each one
of these tests the creation line.
2:23
There we go.
2:28
Perfect.
2:35
Let's get this,
there's the little extra one in there.
2:37
Let's go ahead and we'll run.
2:39
Awesome, the tests all still pass.
2:42
Using that @Before method.
2:43
Now it's possible to have
multiple of these methods that
2:46
are annotated with @Before.
2:50
But remember, that just like the methods
marked with the @Test annotation,
2:52
the order is not guaranteed.
2:56
As you can imagine,
there's also an @After annotation.
2:58
And this will run after
the Test method completes.
3:01
This is handy to think about if say your
code under test was creating a file in
3:04
each method.
3:07
And in that @After method,
3:09
also this was historically known as
tear down, you could delete the file.
3:11
Now, you can of course generate
these methods using code generation.
3:16
They're labeled with their
historically named versions.
3:20
So, if you look in here see
here it's tear down and
3:23
that would create an @After method.
3:27
So lets get a quick review where we got so
far.
3:29
So now what we have
happening is basically this.
3:32
The runner gathers all of
the annotated @Test methods.
3:35
For each @Test the classes instantiated
the method annotated with before
3:38
should run and then the Test method and
then the @After method runs.
3:44
And then it repeats.
3:49
Instantiates a new class, calls before,
calls the method, calls after and so on.
3:50
There are a few more of these fixture
annotations that you should be aware of.
3:56
While the before and after annotations
work for each method, there are types that
4:00
happen once before all of the methods
runs, and once after they all run.
4:04
These are @Before class and @After class.
4:08
Needing to use these @Before class and
@After class often leads to a code but
4:13
I wanted to let you know about
them as you might encounter.
4:17
You typically use this to
setup some complicated or
4:21
expensive operation before all
the text and the pictures run.
4:24
And then you clean it up.
4:27
The reason for this code smell is due
to a best practice that we haven't
4:29
touched on yet, and
that is one of isolation.
4:32
You want to try and make sure that each
behavior on your test is isolated.
4:36
Let's talk more about that and more about
what we should test after this break.
4:40
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up