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
Let's explore how we actually verify, or assert, that our code works as expected.
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
Unit test best practices
have evolved overtime.
0:00
The test community at large
has embraced several acronyms
0:03
that help promote
the writing of good tests.
0:06
This first one you'll hear a lot, and
0:09
it's used to help you remember
how to lay out your tests.
0:11
AAA is this.
0:14
Arrange, in most cases you'll need to
get things all set up before the test.
0:16
To get things in the right
state before the test
0:20
you need to arrange your objects so
they're ready to be tested.
0:22
Act, in the act portion of test you cause
the behavior that your testing to happen,
0:26
whatever that action might be.
0:30
Assert, in the assert portion you verify
that the expected behavior occurred.
0:32
Let's go write some tests
using the AAA style.
0:38
Okay, so
let's work through the tests here.
0:41
This adding funds,
increments available funds.
0:44
Well first actually, let's get rid of
this original test that we have here,
0:47
this failer, let's get rid of that.
0:50
So, first things first,
let's arrange things.
0:52
So in the arranging of this
we need a creditor object.
0:55
Right?
0:58
So let's do that, let's make a creditor.
0:59
Creditor = new Creditor.
1:03
Okay, so that's basically all we
need to do in the arrange phase.
1:11
Right?
1:14
Now sometimes this is all
the arrange portion needs.
1:15
It's just simple object creation.
1:18
Note also how even though the tests
are in a different folder
1:21
they're still in the same
package as the creditor class.
1:24
See how we didn't import
the creditor object at all?
1:27
We didn't.
1:29
It's because they're different folders but
they're in the same package.
1:30
A JUnit style that has emerged
is to separate your AAA
1:33
methods by using a blank
line between each portion.
1:37
So let's do that by starting our second A,
Act.
1:40
So let's add a quarter.
1:45
Now this method addFunds takes an integer,
1:47
I use sense just in case we wanted to
eventually extend this past U.S. currency.
1:52
Okay, and let's go ahead and
we'll add another quarter.
1:59
25 cents.
2:02
Right?
2:03
And now, our final, Assert.
2:08
So what we wanna do is make sure
that there is 50 cents in there.
2:10
Right?
2:14
So, let's just do that.
2:15
In the case that this is new to you,
the verb assert in this case,
2:17
means to verify a fact.
2:21
So remember that the JUnit assert class,
has a ton of static methods for
2:23
checking things that we
statically imported all of them.
2:27
We imported that fail before, remember?
2:30
So let's do the same thing with
the one that we're looking for.
2:32
So we want to assert that
the available funds are 50.
2:34
Right?
2:38
So the method that we want is assert,
you can see there's a whole bunch here,
2:39
equals.
2:44
And now the thing that gets
most people confused when they
2:45
come to this framework is this.
2:48
All of the assert methods parameter
order is [FOREIGN] it is very important.
2:50
Okay, first is the expected value and
then it's the actual value.
2:57
Here look, IntelliJ reminds us.
3:02
It's expected and then it's actual.
3:03
There's an optional
message you can conclude,
3:06
but this is the one that we want.
3:08
See, it's expected and then actual.
3:09
So we want the expected to be 50,
3:13
and then the actual value is
whatever is in available funds.
3:15
Awesome, now we're gonna run it.
3:20
Bam, it passes.
It feels good.
3:23
Right?
3:25
Now, one thing I wanna stress here is that
you always find the right assert method.
3:25
You wanna do this because it
produces awesome error messages.
3:30
Watch this,
let's pop out that second quarter.
3:33
Let's just go ahead and comment this line.
3:34
And then let's run it again.
3:36
Get.
3:38
And see how it says expected 50 and
actual is 25.
3:40
That's pretty awesome.
3:44
That's showing the difference
there right away.
3:44
You can look at that and
see what the problem is.
3:46
So there we go, the AAA in action.
3:49
Now, for those of you who are expecting
a 50 Cent joke like the rapper,
3:52
this test ensures that we will get rich or
it will die trying.
3:56
Okay, so let's practice another one.
4:00
Let's look at the code
over here in creditor.
4:04
And let's see.
4:08
Okay, refund does actually
look pretty interesting here.
4:11
So, let's make sure that
the refund is all of the money and
4:14
that it empties out the available funds.
4:18
Okay, so we'll go ahead and we'll Go To
4:21
> Test, and
again that's Shift+Cmd+T on a Mac,
4:25
and we're gonna choose CreditorTest,
and we'll pop over there.
4:29
So that's, if you don't wanna make a new
one, you can jump back over that way.
4:33
All right, and
we'll generate a new test method.
4:37
And lets name this one
4:40
refundingReturnsAllAvailableFunds.
4:44
Okay, so first we'll arrange.
4:52
Right?
4:54
So we'll need a creditor and
in this case we're also
4:55
gonna arrange the fact that there's
already some funds in there.
4:58
So we'll say creditor.addFunds, and
5:03
we'll just put a dime in there,
ten cents, and then we'll act.
5:07
Okay, so we'll get the results
back from the refund method.
5:13
Right?
5:17
And then we'll assert, and so
again, this one we're gonna assert
5:22
that we expect 10 to be stored
in the variable refund.
5:27
Right?
We would expect our refund to be ten.
5:32
Refunding returns all available funds.
5:34
Perfect.
5:36
Hey, I got an idea.
5:37
While we're in here,
5:39
why don't we also make sure that
the available funds are empty.
5:40
So let's say assertEquals(0
5:43
creditor.getAvailableFunds).
5:47
All right, and we'll run that.
5:53
Beautiful.
5:57
Wait a second.
5:59
Does that test name really
define what is happening?
6:00
What if that second assert fails?
6:04
It wouldn't make, really, sense, would it?
6:08
When it failed, it would say refunding
returns all available funds, but
6:10
that's not true.
6:13
That's not what we're testing there.
6:14
Right?
6:15
So, what I did here was intentionally
break another best practice,
6:17
just so you could see it.
6:20
It's super common.
6:21
You should really shoot for
a single assertion in each test.
6:23
Those assertion errors
work much like exceptions.
6:26
When one is encountered, they immediately
exit and the rest of the code doesn't run.
6:29
So it's possible that both
of those are false and
6:33
we'd have two failing test cases.
6:36
So it's important to separate it out.
6:38
Also I'm starting to see some duplicated
code that we should talk about.
6:39
Great, we did it.
6:46
We practiced the AAAs by Arranging,
Acting and Asserting and
6:48
followed the blank line
style to separate them.
6:52
We did some more static importing
of the amazing JUnit assert.
6:55
I also sort of forced you through
the example of why you might
7:00
not want to have double
assertions in a test.
7:03
It's usually a code smell that you should
probably be writing a separate test.
7:06
After we wrap up here,
you think you could help me correct
7:11
the problem by writing an additional test
to make sure that things are emptied?
7:13
We were definitely starting to repeat
ourselves at the end, weren't we?
7:18
This is something we
want to be careful about.
7:21
We wanna make sure that we take
the same programming best practices and
7:24
apply them to our tests.
7:27
We want legible well thought out tests.
7:29
Just like we want for
our production company.
7:31
The good news is JUnit has
this thought out already.
7:33
There is a way of creating shared
functionality for your tests.
7:37
Let's explore it,
right after this quick break.
7: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