Preview
Video Player
00:00
00:00
Our First Test
6:31Let's start writing some tests!
[MUSIC]
0:00
Let's write some unit tests for
the point class.
0:04
To do this we'll need to create
a project to store our unit tests.
0:07
Unit tests are contained
in their own assembly, so
0:12
that they're separate from the code of the
application, or library that they test.
0:14
This allows us to distribute or
publish the application,
0:19
without shipping the unit test with it.
0:22
There are a number of ways
we can create this project.
0:24
The easiest is to use
the extension we just installed.
0:27
Using this extension we can have
Visual Studio generate the project and
0:31
have it create the scaffold code for
testing the point class for us.
0:35
We just right-click on the name of
the class and click Create Unit Test.
0:39
Make sure that the correct unit
test framework is selected here.
0:47
Because we previously installed
xUnit.net test extensions.
0:51
We can select xUnit.net.
0:54
If we already had a unit
test project set up.
0:56
We could select it here.
0:59
Instead, we'll keep this
set to new test project.
1:01
We can specify the names for
1:05
the project, namespace,
output file and test methods here.
1:06
We'll keep the defaults as there
are fairly standard ways to name these.
1:12
Organizations or teams may have
their own naming conventions,
1:15
in that case you want to change
these to match your teams.
1:19
Finally we pick what we want to start
out with in the test method body.
1:22
I like to have them assert failure,
we'll see what this means in a bit.
1:26
Click on OK to have Visual Studio generate
the unit test project and the scaffold for
1:31
our unit tests for us.
1:36
Let's take a look at what it generated.
1:38
We now have another project in
the solution named TreehouseDefense.Tests.
1:41
This is our unit test project.
1:46
The extension created the project and
1:48
installed all the NuGet
packages that are needed.
1:50
Let's take a quick look at these packages.
1:53
Just right click on the project and
then click Managed NuGet packages.
1:55
Here we see the NuGet packages
that are needed for xUnit to work.
2:01
This final one here is a test runner.
2:04
Visual Studio uses this package to
execute tests and get the results.
2:07
There's also a console version of this
package which can be used to execute
2:12
tests from the console.
2:15
Which is handy for
2:17
when we don't want to have Visual Studio
open in order to run our tests.
2:18
It can be installed as
a separate NuGet package.
2:22
We didn't need to use the extension
to set up our test project.
2:25
The test project is just
a C# class library.
2:29
We could have created the project and
2:32
downloaded the individual
NuGet packages ourselves.
2:34
I just find using the extension
a lot more convenient.
2:37
Inside the project that was generated,
we have one file called point test.
2:41
It contains the test class for
the point class.
2:46
A test method was created for
each public method in the point class.
2:49
This is where we write our test.
2:54
Notice that above each test method
there's an attribute named fact.
2:57
You may not be familiar
with attributes in C#.
3:01
Attributes allow us to annotate
the code with additional information.
3:04
This information can be used
by the compiler at runtime
3:09
using a feature of .Net called reflection.
3:12
In this case the attribute is used to tell
the unit test runner that this method
3:15
is a test method.
3:19
MS test and N unit also use
attributess to denote a test.
3:20
MS tests names this attribute test method.
3:25
And N unit simply names it test.
3:28
But all three have the same effect.
3:30
You can pass parameters to attributes,
but we don't need to right now.
3:32
Parentheses are optional
if there are no parameters.
3:35
Now our task is to write unit
test cases for the point class.
3:39
Let's start by testing that
the constructor of the point class is
3:43
coded correctly.
3:46
We'll put this code in the first
method named point test.
3:47
When writing unit test,
3:51
we follow a very simple pattern
which is arrange, act, assert.
3:52
First, we prepare to perform
an operation by arranging our data.
3:57
If we look at the point constructor,
we'll see that it takes two parameters.
4:02
We have x and y.
4:07
In our test we'll need to decide
what will pass the constructor.
4:09
So I'll say int x = 5 and int y = 6.
4:14
Now we need to execute the operation.
4:23
This is the act part of the pattern.
4:26
In this case we'll construct
a point with these parameters.
4:28
So I'll say var point = new Point and
pass in x and y.
4:31
Now, we need to verify that the x and
4:40
y fields in the point
object were set correctly.
4:42
This is called an assertion.
4:45
Because we are asserting that something
is the way we expected to be.
4:47
If the assertion fails, the test fails.
4:51
Here we already have an assertion but
4:54
we'll need to change it to something
that makes sense for this test.
4:56
So I'll say Assert.Equal(x),
which is what we expect,
4:59
and point.X,
which is what was actually set.
5:06
We'll also check Y.
5:12
So there you go.
5:18
There's the test.
5:20
When this test passes, we can be
sure that the fields of the class
5:21
are initiated to the correct set of values when it's instantiated.
5:25
You may be thinking this was
a pretty dumb thing to test.
5:28
And yes, a lot of unit tests,
test dumb things like this.
5:32
But a bunch of little dumb tests add up
to ensuring that we have high quality
5:36
software and peace of mind.
5:40
Let's say when I was
coding the point class,
5:42
that I did something like
this in the constructor.
5:44
It was an honest mistake.
5:51
X and Y are really common variable names.
5:53
Especially when coding for 2D graphics.
5:56
In reality, I get x and
y mixed up all the time.
5:59
Seriously, I mean all the time.
6:03
And before I was religious about writing
unit tests, I often wouldn't discover
6:05
what I did until things started moving
across the screen in the wrong direction.
6:10
Then, I'd have to go track
down where I went wrong.
6:14
This meant inspecting all of the hundreds
of x and y's in the program.
6:18
It's enough to make someone go insane.
6:22
I'm not kidding.
6:24
Writing a dumb little test method
like the one we just wrote
6:25
is well worth the peace
of mind that it brings.
6:28