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