Awesome.

Thanks for cleaning up that test for us.

We are definitely starting to repeat ourselves.

And even in test land, we want to make sure that we keep dry.

In order to fully understand the way to fix this don't repeat yourself problem.

I first want to make sure that we understand more or less what has happened.

First of all,

these classes that contain the methods marked with Test are called fixtures.

They have some hidden powers that we haven't talked about yet.

When you kick off the Test runner, what happens is that each method

that is annotated with the @Test annotation is gathered.

[SOUND] The runner then loops through each test.

And for each test that it instantiates, it creates a brand new object and

runs that single method.

There is no guaranteed order to those tests.

So because each class gets it's own instance you can actually add

fields to the class definition and each of the methods can access those.

You might think you add a constructor to initialize these but that isn't the case.

There is a special type of annotation called a fixture annotation that

helps us out.

It's named @Before.

We use it to annotate methods that then set things up.

So what do you say we stop repeating ourselves?

What do you say we stop repeating ourselves?

What do you say we stop repeating ourselves?

See how annoying that is.

Let's stop doing that.

Okay, so let's take care of that repeating perpetrator.

So just looking at this I can see the problem that we're creating is

each of these tests is instantiating a new creditor object, right.

This one is, that one is, this one is,

we're doing the exact same thing in each method.

So let's add a new before method.

Now, historically when these were created in the past,

they needed to be called set up.

It was a specific naming convention, so like when you set up before each method.

So if we go to Generate, so again it's Code, Generate and we're

going to do the SetUp Method, which is gonna give us one of those before methods.

Okay.

And here we are going to get a new creditor object.

And of course it doesn't know what we're talking about.

So let's go ahead and we will create a field called Creditor and that's fine.

All right, so now the test instance has access to a creditor.

So now we can get rid of in each one of these tests the creation line.

There we go.

Perfect.

Let's get this, there's the little extra one in there.

Let's go ahead and we'll run.

Awesome, the tests all still pass.

Using that @Before method.

Now it's possible to have multiple of these methods that

are annotated with @Before.

But remember, that just like the methods marked with the @Test annotation,

the order is not guaranteed.

As you can imagine, there's also an @After annotation.

And this will run after the Test method completes.

This is handy to think about if say your code under test was creating a file in

each method.

And in that @After method,

also this was historically known as tear down, you could delete the file.

Now, you can of course generate these methods using code generation.

They're labeled with their historically named versions.

So, if you look in here see here it's tear down and

that would create an @After method.

So lets get a quick review where we got so far.

So now what we have happening is basically this.

The runner gathers all of the annotated @Test methods.

For each @Test the classes instantiated the method annotated with before

should run and then the Test method and then the @After method runs.

And then it repeats.

Instantiates a new class, calls before, calls the method, calls after and so on.

There are a few more of these fixture annotations that you should be aware of.

While the before and after annotations work for each method, there are types that

happen once before all of the methods runs, and once after they all run.

These are @Before class and @After class.

Needing to use these @Before class and @After class often leads to a code but

I wanted to let you know about them as you might encounter.

You typically use this to setup some complicated or

expensive operation before all the text and the pictures run.

And then you clean it up.

The reason for this code smell is due to a best practice that we haven't

touched on yet, and that is one of isolation.

You want to try and make sure that each behavior on your test is isolated.

Let's talk more about that and more about what we should test after this break.