This course will be retired on July 14, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Unit Testing in C#!
You have completed Unit Testing in C#!
Preview
Test Driven Development (TDD) ensures that unit testing is not an afterthought.
This video doesn't have any notes.
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
[SOUND] Historically,
the task of writing unit
0:00
tests began after the unit
of code was written.
0:04
Unfortunately, this all too often meant
that there was still a strong temptation
0:09
to skip unit testing, put it off until
the entire project was nearly complete or
0:14
only do partial testing.
0:19
Here's a conversation often heard between
two developers or a developer and
0:22
their boss.
0:26
>> Hey have you finished component x?
0:27
>> It's all coded, I just need to test it.
0:30
People who write quality
software know that code
0:32
isn't complete until it's tested for
a while.
0:35
For awhile, people have been thinking
about ways that unit testing could
0:38
be more integrated into the development
cycle so that it couldn't get overlooked.
0:41
One idea was to write the test
before writing the code.
0:46
This way every unit of code is tested
before it can be said to be complete.
0:50
This idea is called test-driven
development or TDD for short.
0:56
And it's quickly becoming the standard
practice in the software industry.
1:00
This may sound counter-intuitive to you.
1:05
It was to me too when I first heard of it.
1:08
I was used to first writing my code and
then testing it.
1:10
It didn't make sense that
it could be any other way.
1:14
The thing is it makes a lot of sense.
1:17
After all before coding a class or
1:19
method, we have some idea of what
the classroom method should do.
1:21
This information may come from a document
such as a functional specification or
1:26
a detailed design specification.
1:31
A specification is written documentation
about how something should work or
1:33
how it should be put together.
1:38
In my experience, more often than not,
1:40
I'm not provided that level of detail
about how a class should be coded.
1:42
This means I'm often working
from an informal specification.
1:47
Before I start coding,
1:51
I often draw out a few diagrams
of how I think things will work.
1:52
You can do this with a tool or
any piece of paper.
1:56
Napkins work good too.
1:59
I'll have an idea about which
classes I need to code and
2:02
how they'll work together.
2:05
For simpler projects,
it may just be an idea in my head.
2:06
The point is,
we have an idea of what the class and
2:10
methods will look like
before we start coding them.
2:13
And this means that we can write
tests to specify how the code we're
2:16
writing should work.
2:20
When doing test-driven development,
2:21
we follow a simple pattern
called red-green-refactor.
2:24
First, we create the stubs for
the class and its public members.
2:28
A method stub is code
that doesn't do anything.
2:32
It just determines the method's name,
its return value, and the names and
2:35
types of its parameters.
2:39
All the details of the method
will be written later.
2:41
Now that we have a method
that we can call,
2:45
we'll write the test that we expect to
pass in order to prove that the method or
2:47
perhaps the entire class works correctly.
2:51
Then we run these tests.
2:54
The point of running the test
before actually writing the code
2:56
is to verify that all of the tests fail.
2:59
If they don't fail there's obviously
something wrong with the test.
3:02
In short all the tests should
show up red in the test Explorer.
3:06
Now we write the code for
the unit that we're testing.
3:12
At this point,
3:14
we're only concerned about making
sure that the code works as expected.
3:15
It doesn't have to be
the most elegant solution.
3:20
After we've done this, we run
the test again and debug the code and
3:23
test until they all turn green.
3:26
Usually about this time,
we'll discover some corner cases
3:29
that we may not have thought about
when writing the original test.
3:32
So, we'll write some more tests.
3:35
Now that we know that we've got
the correct test, and they all pass.
3:38
We can take a second look at
the code to see if there's
3:41
anything that could be improved.
3:44
Perhaps, we could write it more elegantly,
make it more readable or
3:46
improve the performance so
that it runs faster.
3:49
This is the refractor step
of red-green-refractor.
3:52
We can come back and
refactor at any time as often as we want.
3:56
We can feel confident when
refactoring the code because we
4:00
already have all the tests to tell us if
we screwed anything up in the process.
4:03
With test driven development
as soon as the code is written
4:09
then the code is complete.
4:12
Instead of saying,
it's coded I just need to test it.
4:13
You'll get to say, yep it's all done.
4:16
TDD has other benefits too.
4:19
Ensures that code is unit testable.
4:22
It often discovers design flaws
before the code is written and
4:24
it helps us think through the problem
before we write the code.
4:28
Many of the benefits of TDD aren't
apparent until we've done it ourselves.
4:32
So let's use test driven development
to code up the next part
4:36
of the tree house defense game.
4:40
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