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
Preview
Video Player
00:00
00:00
00:00
- 2x 2x
- 1.75x 1.75x
- 1.5x 1.5x
- 1.25x 1.25x
- 1.1x 1.1x
- 1x 1x
- 0.75x 0.75x
- 0.5x 0.5x
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