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
Let's see how to approach coming up with test cases.
Behavior Driven Development provides good ideas on how to name test methods.
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
Visual Studio created one test method for
each public method in the point class.
0:00
But in reality, we'll usually have
more than one test method for
0:05
each method in the target.
0:09
We treat each test method as a test case.
0:11
For example, we created a test for
the distance to method for
0:14
the distance between (0, 0) and (3, 4).
0:18
However this is just one possible case.
0:22
There are countless other
scenarios we could test.
0:25
We can't possibly make tests for
every combination of points.
0:28
This is where our good judgment comes in.
0:32
I find it best to break up
the scenarios into groups and
0:34
then write one or
two tests for each group.
0:38
If the test for
a group of scenarios passes,
0:41
then I can extrapolate that the code will
work for all the scenarios in that group.
0:43
For example one group of tests could be
points that are horizontally aligned,
0:47
another group are vertically
aligned points.
0:52
Another are points that
are diagonal from each other.
0:55
There's also the case where two
points are in the same position.
0:58
These are some of the basic cases.
1:02
We also need to think about edge cases.
1:05
Edge cases are cases when the input
parameters are at the extreme
1:08
end of what the code should accept.
1:12
For example, we could test what happens
when a point is passed in whose x and
1:13
y values are the maximum values for
what can be stored in an integer.
1:19
In addition to edge cases
we can have corner cases.
1:23
Corner cases are cases that
shouldn't normally happen but
1:27
we need to make sure that the code handles
it gracefully if it's expected to.
1:31
Things like what happens if null is passed
in or a point with negative x or y values.
1:35
We often learn the most about our code
when considering edge or corner cases.
1:42
That said, we also need to use our
judgement regarding the practicality of
1:47
many of these tests.
1:50
After all,
1:52
distance too is a single line method
that does a straightforward computation.
1:53
Three or four tests should be enough to
prove that it's implemented correctly.
1:57
For example, we could assume that if
the method is able to accurately compute
2:02
the distance to a point where both
the x and y values are different.
2:06
Then it can also do so when only the x or
y value are different.
2:10
It comes down to our comfort level
with making that assumption.
2:15
Experience with testing helps too.
2:18
At the very least, let's write
another test that verifies that
2:21
two points in the same location
have a distance of zero.
2:24
We'll write another test
of the DistanceTo method.
2:28
We'll need to name this something
different than DistanceToTest
2:31
since we already have
a method with that name.
2:34
We can name it whatever we want.
2:37
There are a number of different
conventions that folks
2:39
use when creating test names.
2:41
Since no one actually has to call these
methods, we can make the names for
2:44
test methods longer
than we normally would.
2:47
I prefer to name test methods so that they
describe the case that they're testing.
2:50
Another convention is to put the name of
the method that's being tested first,
2:55
followed by an underscore and
the name of the test case.
2:59
This is fine, many test cases
are testing the behavior of the unit and
3:02
not just the results of calling
a single method though.
3:06
The important thing is that test cases can
be distinguished from each other based on
3:09
what they're testing by
looking at their name.
3:14
So I'll name this new test
DistanceToPointAtSamePosition.
3:17
So I'll say Fact, then public void
3:21
DistanceToPointAtSamePosition.
3:27
For this test, let's just go ahead and
copy what we already wrote for
3:37
the previous test.
3:40
We'll make both the point and
the target the same place.
3:46
So I'll say (3, 4) and the expected
distance between them should be (0, 0).
3:49
So there you go.
3:57
That's all we need for this test.
3:58
I'll change the name of the other
method to something like DistanceTo,
4:00
WithPythagoreanTriple, because 3, 4, and
4:07
5 are whole numbers that form
the sides of a right triangle.
4:11
Otherwise known as a Pythagorean triple.
4:17
We could write a couple more test
cases for the Point class but
4:20
I'll leave that up to you so
we can move on.
4:23
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