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