Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
The second phase of red-green-refactor is to implement the code under test to make the tests pass.
-
0:00
In the previous video, we ran our test to make sure that they all failed.
-
0:03
This is centrally checks that they're testing what we expect them to test.
-
0:07
With that out of the way, we can move on to making our test pass.
-
0:11
Before we do that we should pause to notice, that before we've even written any
-
0:15
code in the path class our self we already have the test.
-
0:19
We'll need to test that it works by writing code that uses our class to method
-
0:23
first, we've given more thought to how it should be implemented.
-
0:27
And now, we're ready to actually implement it.
-
0:30
So, let's go into the path class again.
-
0:33
And the IsOnPath method here.
-
0:35
We'll get rid of the throw in exception.
-
0:38
And now, let's implement this method.
-
0:40
So is on path will return true if the map location passed in,
-
0:45
is inside of this path locations array.
-
0:49
So we can use the array classes index of method to determine that.
-
0:53
So we'll return array.index of with the path locations array and
-
1:00
we'll search for the mapLocation passed in.
-
1:06
And if that returns something that's greater than or equal to zero,
-
1:11
then we've found the map location in the path.
-
1:15
So it turns out that IsOnPath is a fairly simple method to implement.
-
1:19
Let make sure that our implementation works by running the tests that we've
-
1:23
already written.
-
1:24
So we're going to test Explorer and just run those tests again.
-
1:31
So map location is not on path passes.
-
1:35
But map location is on path fails and
-
1:39
it fails because is on path returned false when we expected it to return true.
-
1:48
Let's take a look at our implementation again I can't see anything wrong here.
-
1:53
So let's take another look at the test.
-
1:57
I think I see what's happening.
-
2:00
So MapLocation is a class.
-
2:02
The indexOf method calls the equals method on items in
-
2:06
the array to determine that the object passed in equals anything in the array.
-
2:12
But the equals method by default
-
2:14
only determines if two objects are the same object.
-
2:17
In our case, our tests aren't passing in the MapLocation object that's
-
2:22
stored in the path.
-
2:23
We're passing in a brand new map location object here.
-
2:27
It just happens to have the same coordinates as one that's
-
2:30
already on the path.
-
2:31
So we need to fix this somehow.
-
2:33
There are a number of ways that we can fix this.
-
2:36
We could change the way the is on path method is implemented so
-
2:39
that it loops through each map location on the path and compares the x and
-
2:43
y coordinates instead of just the objects.
-
2:45
Or we could override the equals method in the map location or
-
2:49
in its parent point class.
-
2:51
So that it returns true if x and y coordinates match.
-
2:55
Let's go with the second option and
-
2:57
overwrite the equals method of the point class.
-
3:00
So map location will inherit this new equals method.
-
3:04
We'll use test driven development to code the equals method, so I'll go in
-
3:09
to the point test class, and I'll write some test for the equals method first.
-
3:20
So here's our test for the equals method.
-
3:23
Notice that I also added some test for, get hash code,
-
3:27
because whenever we override equals, we should also override get hash code.
-
3:34
Let's take a look at these real quick.
-
3:36
So I've got a test to make sure that null is not equal to a point.
-
3:40
I've got test for when objects are equal and I've got test for
-
3:44
when objects are not equal.
-
3:46
For get hash code I've got a test for
-
3:48
similar points that should have different hash codes.
-
3:52
Another one for similar points that should have different hash codes.
-
3:55
And one for points that should have the same hash code.
-
4:00
With these tests in place, I can write the code for equals and get hash code.
-
4:05
So here's the methods for equals and get hash code.
-
4:08
Now we can run the test again to verify the equals and
-
4:11
get hash code are implemented correctly.
-
4:14
So I'll go in to point tests and run these tests.
-
4:29
Okay, it looks like those all passed.
-
4:31
Let's go ahead and run all the tests in our project.
-
4:44
Looks like everything passed, including our two path test methods.
-
4:49
Overriding the equals method is a change that could've had repercussions
-
4:53
over the entire program.
-
4:55
However, we can make changes like this confidently because we
-
4:58
already have test to check to make sure that everything else still works.
-
5:02
All the tests we've written so far can be run again.
-
5:05
This is called regression testing and it's one of the many wonderful
-
5:09
things about unit testing and test driven development.
-
5:12
With proper test driven development, we never have to wonder
-
5:15
if making changes to the code will break some other part of the program.
-
5:19
So now that our test pass,
-
5:21
we can move on to the next stage of test driven development, refactor.
You need to sign up for Treehouse in order to download course files.
Sign up