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
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