In the previous video, we ran our test to make sure that they all failed.

This is centrally checks that they're testing what we expect them to test.

With that out of the way, we can move on to making our test pass.

Before we do that we should pause to notice, that before we've even written any

code in the path class our self we already have the test.

We'll need to test that it works by writing code that uses our class to method

first, we've given more thought to how it should be implemented.

And now, we're ready to actually implement it.

So, let's go into the path class again.

And the IsOnPath method here.

We'll get rid of the throw in exception.

And now, let's implement this method.

So is on path will return true if the map location passed in,

is inside of this path locations array.

So we can use the array classes index of method to determine that.

So we'll return array.index of with the path locations array and

we'll search for the mapLocation passed in.

And if that returns something that's greater than or equal to zero,

then we've found the map location in the path.

So it turns out that IsOnPath is a fairly simple method to implement.

Let make sure that our implementation works by running the tests that we've

already written.

So we're going to test Explorer and just run those tests again.

So map location is not on path passes.

But map location is on path fails and

it fails because is on path returned false when we expected it to return true.

Let's take a look at our implementation again I can't see anything wrong here.

So let's take another look at the test.

I think I see what's happening.

So MapLocation is a class.

The indexOf method calls the equals method on items in

the array to determine that the object passed in equals anything in the array.

But the equals method by default

only determines if two objects are the same object.

In our case, our tests aren't passing in the MapLocation object that's

stored in the path.

We're passing in a brand new map location object here.

It just happens to have the same coordinates as one that's

already on the path.

So we need to fix this somehow.

There are a number of ways that we can fix this.

We could change the way the is on path method is implemented so

that it loops through each map location on the path and compares the x and

y coordinates instead of just the objects.

Or we could override the equals method in the map location or

in its parent point class.

So that it returns true if x and y coordinates match.

Let's go with the second option and

overwrite the equals method of the point class.

So map location will inherit this new equals method.

We'll use test driven development to code the equals method, so I'll go in

to the point test class, and I'll write some test for the equals method first.

So here's our test for the equals method.

Notice that I also added some test for, get hash code,

because whenever we override equals, we should also override get hash code.

Let's take a look at these real quick.

So I've got a test to make sure that null is not equal to a point.

I've got test for when objects are equal and I've got test for

when objects are not equal.

For get hash code I've got a test for

similar points that should have different hash codes.

Another one for similar points that should have different hash codes.

And one for points that should have the same hash code.

With these tests in place, I can write the code for equals and get hash code.

So here's the methods for equals and get hash code.

Now we can run the test again to verify the equals and

get hash code are implemented correctly.

So I'll go in to point tests and run these tests.

Okay, it looks like those all passed.

Let's go ahead and run all the tests in our project.

Looks like everything passed, including our two path test methods.

Overriding the equals method is a change that could've had repercussions

over the entire program.

However, we can make changes like this confidently because we

already have test to check to make sure that everything else still works.

All the tests we've written so far can be run again.

This is called regression testing and it's one of the many wonderful

things about unit testing and test driven development.

With proper test driven development, we never have to wonder

if making changes to the code will break some other part of the program.

So now that our test pass,

we can move on to the next stage of test driven development, refactor.