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 third phase of red-green-refactor is to improve the implementation without breaking the tests.
Now, that we have all
of our tests passing.
0:01
We can go back and see if there's
anything we can improve about our code.
0:03
Changing code without changing its
apparent functionality is called
0:07
refactoring.
0:11
Here are a few reasons we
would want to refactor code.
0:12
It can make the code easier for
others to read and comprehend.
0:15
It can make the code easier to maintain.
0:19
It could make it more efficient or faster.
0:22
It could make it easier to
add additional code in later.
0:25
Sometimes refactoring is done just to make
the code compliant with best practices and
0:28
conventions the others expect.
0:33
When coding there's a tendency to
try to make every line of code
0:35
beautiful and elegant.
0:39
Beautiful and elegant code is great,
and is often a good goal, but
0:40
we're trying to solve a problem first.
0:44
This often means writing and
0:46
rewriting code until we finally
settle on something that just works.
0:48
With test-driven development we don't
wanna spend too much time making our code
0:52
pretty, if we don't even know
if it'll pass the test yet.
0:56
In other words we don't wanna
spend a lot of time sculpting or
1:00
polishing our code, only to find
out that it doesn't pass the tests.
1:03
A quick note on elegant code.
1:08
We also want to remember that
other people will probably work
1:10
on our code in the future.
1:13
So we want to balance elegance and
conciseness with clarity and readability.
1:15
I remember writing an elegant
function once upon a time.
1:20
That a senior programmer kindly pointed
out would be difficult to maintain for
1:23
newcomers who are not familiar
with some of the syntax I used.
1:27
We also don't want to worry too much
about performance at this point.
1:32
The main purpose of unit test is to
test the functionality of a unit.
1:35
Not necessarily how efficiently it runs.
1:39
Performance can be affected by
a lot of things that a unit test
1:42
can't capture and control.
1:46
Exerting unnecessary effort on
this level of detail is known as
1:48
premature optimization.
1:52
We should try to figure
code working first and
1:54
then decide if it's worth it
to make further optimizations.
1:57
Knowing how much is good enough,
2:01
is a skill that can only be
learned through experience.
2:02
Now that our tests are written, and
we have a working implementation,
2:06
we can refactor and
optimize to our heart's content.
2:09
And we have our unit test to
back us up that all the way.
2:13
Let's take a look at the path class again.
2:16
The first thing I see is Visual Studio
2:19
didn't name things the way
I like them named.
2:21
For example this pathLocations field.
2:24
I prefer it named _path.
2:26
So I'll rename this using a refactor.
2:29
To use the rename refactor in
Visual Studio just hold down Ctrl and
2:32
Type R R twice.
2:36
Now I can just type in the name I want.
2:38
So we'll say _path.
2:40
Notice how it updates everywhere
without variable's being used.
2:42
I'll get rid of this.
2:45
Also silly me, I should have written
the IsOnPath method much more
2:49
by using the contains
method provided by link.
2:54
I'll put this all in one line.
2:56
So I just change this
to be _path.Contains,
2:59
and contains the link method.
3:06
You need to add the using.
3:10
And we'll pass in map location.
3:13
Visual Studio provides many
other refactoring tools that
3:18
are worth checking out.
3:21
The great thing about doing
refactoring in Visual Studio,
3:23
is that it can make changes in all the
projects of a solution at the same time.
3:26
For example, changing the name of
the IsOnPath method using the rename
3:31
refactoring also changes it
everywhere else in the solution.
3:35
This is really helpful when we need to
update all the tests that are calling
3:39
the IsOnPath method.
3:43
With that done let's run the test
again to make sure that nothing broke.
3:44
Excellent, everything still passes.
3:52
With that we've successfully used test
driven development to code the path class.
3:54
We can go tell our boss that this class is
complete, not just coded, but complete.
4:00
You need to sign up for Treehouse in order to download course files.
Sign up