Preview
Video Player
00:00
00:00
Defining a Unit
3:34What exactly is this unit we are testing?
There are different types
of automated tested and
0:00
as I originally stated we're gonna
be focusing on unit testing.
0:02
So that of course probably
triggered you to ask the question,
0:07
well what's this unit that's being tested?
0:09
I'm glad you asked.
0:13
A unit in this case is unfortunately one
of those self contained definitions.
0:15
The most definition used is this.
0:18
Unit.
0:22
The smallest testable
part of an application.
0:22
That's not a very satisfying answer,
is it?
0:25
I mean sometimes this is clear,
but often times it's not.
0:27
This lack of a proper definition
definitely causes some confusion and,
0:31
of course, arguments amongst developers.
0:35
So how do you locate
the smallest testable part?
0:39
Well, a pretty straightforward
logical approach to finding
0:42
units in your application is to look
at every publicly available method.
0:45
In fact,
most IDEs actually will do this for you.
0:50
This is what they do when you
create a test from a template.
0:53
They'll build a single test for
each method.
0:57
However, this is one of those places where
we developers have yet to be replaced.
1:00
The code generation here doesn't
actually understand our code, does it?
1:06
It doesn't understand what it
is that out code actually trying
1:09
to accomplish, but we do.
1:12
So here's the thing, let's define our
unit test as testing a unit of work.
1:15
Now a unit of work is something
that causes publicly exposed
1:21
behavior to occur for users of our code.
1:25
Typically, you can gather the units of
work by looking at the public facing API.
1:29
An API, or
Application Programming Interface,
1:34
is the methods that have been publicly
exposed to users of your code.
1:37
Remember that when we
declare methods public
1:43
we're defining how we want those
users to interact with our objects.
1:45
And the beauty of that
encapsulation is this.
1:49
As long as the results
are the same from each method,
1:52
we're free to change
the implementation however we want.
1:55
Specifically, how we perform the requested
behavior when the method is called.
1:58
We might change the implementation
by making the code cleaner.
2:03
Maybe we'll make it faster, or
have it use other existing code.
2:06
But the point is this.
2:10
The only guarantee to users of your code
2:11
is that publicly exposed behavior
will behave as you expect it will.
2:14
And that's all we're really after, right?
2:20
We want to find the publicly exposed
behavior or units of work and
2:22
ensure that it does indeed
work the way that we intended.
2:26
Whether that be a return value or
an internal state change or
2:29
even that misusing it causes
an expected exception.
2:33
So if we're only dealing with
the public facing behavior,
2:37
how do we ensure that all the private,
magical code we have works?
2:41
You know, we don't want to
break the DRY practice, so
2:46
we want to make reusable functions.
2:48
And also, sometimes we don't want to
expose the inner-workings of our object.
2:51
So surely, there must be some
way to work around this, right?
2:55
Well, there is a better way.
2:59
And in fact, just thinking about how
to tackle testing public behavior,
3:00
is gonna do just like I said earlier.
3:04
It's gonna make us code better.
3:06
It's going to drive home
important programming concepts.
3:08
Testing will help you code in
a more professional manner.
3:12
So, in order to get us there,
3:16
it'll help us to have a more
concrete example to work with.
3:18
Thinking about programing in the abstract
can sometimes feel overwhelming, and
3:21
sometimes you just need to dive in.
3:25
After a quick exercise let's do just that.
3:27
Let's jump into the project for
this course,
3:29
which will help us explore
these new concepts.
3:32