Now, that we have all of our tests passing.

We can go back and see if there's anything we can improve about our code.

Changing code without changing its apparent functionality is called

refactoring.

Here are a few reasons we would want to refactor code.

It can make the code easier for others to read and comprehend.

It can make the code easier to maintain.

It could make it more efficient or faster.

It could make it easier to add additional code in later.

Sometimes refactoring is done just to make the code compliant with best practices and

conventions the others expect.

When coding there's a tendency to try to make every line of code

beautiful and elegant.

Beautiful and elegant code is great, and is often a good goal, but

we're trying to solve a problem first.

This often means writing and

rewriting code until we finally settle on something that just works.

With test-driven development we don't wanna spend too much time making our code

pretty, if we don't even know if it'll pass the test yet.

In other words we don't wanna spend a lot of time sculpting or

polishing our code, only to find out that it doesn't pass the tests.

A quick note on elegant code.

We also want to remember that other people will probably work

on our code in the future.

So we want to balance elegance and conciseness with clarity and readability.

I remember writing an elegant function once upon a time.

That a senior programmer kindly pointed out would be difficult to maintain for

newcomers who are not familiar with some of the syntax I used.

We also don't want to worry too much about performance at this point.

The main purpose of unit test is to test the functionality of a unit.

Not necessarily how efficiently it runs.

Performance can be affected by a lot of things that a unit test

can't capture and control.

Exerting unnecessary effort on this level of detail is known as

premature optimization.

We should try to figure code working first and

then decide if it's worth it to make further optimizations.

Knowing how much is good enough,

is a skill that can only be learned through experience.

Now that our tests are written, and we have a working implementation,

we can refactor and optimize to our heart's content.

And we have our unit test to back us up that all the way.

Let's take a look at the path class again.

The first thing I see is Visual Studio

didn't name things the way I like them named.

For example this pathLocations field.

I prefer it named _path.

So I'll rename this using a refactor.

To use the rename refactor in Visual Studio just hold down Ctrl and

Type R R twice.

Now I can just type in the name I want.

So we'll say _path.

Notice how it updates everywhere without variable's being used.

I'll get rid of this.

Also silly me, I should have written the IsOnPath method much more

by using the contains method provided by link.

I'll put this all in one line.

So I just change this to be _path.Contains,

and contains the link method.

You need to add the using.

And we'll pass in map location.

Visual Studio provides many other refactoring tools that

are worth checking out.

The great thing about doing refactoring in Visual Studio,

is that it can make changes in all the projects of a solution at the same time.

For example, changing the name of the IsOnPath method using the rename

refactoring also changes it everywhere else in the solution.

This is really helpful when we need to update all the tests that are calling

the IsOnPath method.

With that done let's run the test again to make sure that nothing broke.

Excellent, everything still passes.

With that we've successfully used test driven development to code the path class.

We can go tell our boss that this class is complete, not just coded, but complete.