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 Java!
You have completed Unit Testing in Java!
Preview
Don't judge me! I wrote this on a plane and quickly, let's go over the pitfalls of what happened.
Learn more
- The Learn Java track uses the coding style suggested in the Android Contributors Code Style Guidelines doc
- Test Driven Development - TDD with some wisdom.
- Detailed look into TDD
Requests
- Want a workshop on Test Driven Development? Vote it up and make your voice heard!
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
While I was on that tiny plane,
in my tiny seat,
0:00
I coded up a bit of the prototype
on my regular sized laptop.
0:02
I worked out a pretty rough prototype of
a solution to share with our larger than
0:06
life Texan, Tex.
0:11
I told Tex that in our coding
adventures most of us haven't quite yet
0:12
covered communicating with a tiny
computer, like the Raspberry Pi or
0:16
the Arduino, but the solution
that we ended up providing would
0:19
probably look something similar to that.
0:22
We put a microcomputer in
each of those machines and
0:25
use it to communicate
with the different parts.
0:28
I asked if he could just imagine
what we are trying to do.
0:31
The code will be similar, but all the user
interface will be through the keyboard.
0:34
He responded with, sure enough, partner!
0:38
The project was going
better than I thought,
0:40
he already considered us partners.
0:42
So the prototype that I whipped up,
I put it up on GitHub for us to share.
0:44
We'll get it working on your
local machine here in a bit, but
0:48
I wanted to talk you through just
a little bit of the code first.
0:51
Before we get started,
0:54
I want to let you know that this course is
going to use a slightly different coding
0:55
style than the one that we used previously
in the Learn Java track In that track,
0:59
we prefixed private member
variables with an M character.
1:04
Now we were following the Android
contributor's guideline style and
1:07
here it is,
as you work on different teams,
1:11
you're gonna need to adhere to different
coding styles, so we should practice that.
1:14
But see here, it says that non public,
1:18
non static field names start with an m,
and here's an example of it, right?
1:20
Remember we were doing this,
we were prefacing things with an m and
1:24
I was making sure that
you were doing that, but
1:26
now, let's practice a different style.
1:29
Check the teacher's notes for more info.
1:31
It turns out that things are a little more
difficult in vending machines that you'd
1:33
originally think.
1:36
So let's take a peek at the first pass
original draft on GitHub that I wrote
1:38
of the vending machine itself,
it's over here.
1:42
So, here's the class VendingMachine, and
1:45
first, let's take a look
at the new coding style.
1:47
So, notice how the member variable here,
1:49
notifier, doesn't have
the m prefix in the name.
1:51
And see how in the constructor here
the word notifier is passed in,
1:55
and the parameter is defined
to have the same name.
1:59
So to ensure that we're talking
about the member variable, and
2:03
not the local argument, we prefix
the field with the key word this,
2:05
just like this.
2:10
So it's talking about this notifier,
2:13
which is this notifier, and
this notifier here is this notifier.
2:15
A little bit confusing and that's why
the style was originally in place,
2:19
but don't worry, the ID helps you out.
2:22
So hey look, here is the multidimensional
array of bins that we talked about before.
2:24
When you construct the machine,
you tell it how many rows and
2:29
columns that you want.
2:31
Now note how the field here is private,
it's encapsulated.
2:33
That means that we can change this
implementation later if we want to.
2:37
All right, so, wow,
look at all the code in here.
2:40
It's kinda hard to tell exactly
what it's doing, isn't it?
2:45
Boy, yikes I was really
rushing when I wrote this,
2:50
I see only a few public methods and then
there's a lot of these private methods.
2:53
This is the hints of what
is known as a code smell,
2:59
the signs that something might be wrong.
3:03
Now the code smell is specifically this,
3:05
lots of private methods is a sign
that some refactoring may be needed.
3:08
Let's take a look at what these are doing,
oh, okay, right, I remember.
3:13
So, this one here is taking care
of translating the letter and
3:19
the number that somebody enters, right?
3:22
So they enter A2 and it translates
it to the right row and column.
3:24
And then there was some stuff up here, and
3:30
this was kind of managing the credit
that people are putting in the machine.
3:32
Like for
3:36
the current session that you're going
through while you're using the machine.
3:36
Wow, this class sure is doing a lot,
do you think it's doing too much?
3:41
If you answered yes to the question
that I asked about the class doing too
3:47
much, you're right.
3:49
It's totally doing too much.
3:51
There's a principle in object
oriented programming called
3:53
a Single Responsibility Principle.
3:56
And it is this, every class should
have responsibility over a single part
3:58
of functionality provided by the software.
4:02
Now it's often shortened to this rule,
4:05
a class should only have
one reason to change.
4:07
So really,
4:11
the vending machine's responsibility is
actually really only one thing right?
4:12
I mean, in terms of user interacting with it.
4:16
Vend.
4:18
All this other code that I wrote
is kinda questionable right?
4:20
It deals with crediting and
translating the choice.
4:22
I mean, is that really the responsibility
of the machine itself?
4:25
It's kinda the responsibility of
different parts of the machine, or
4:29
better yet
the different components of the machine.
4:33
Hm, it's like this machine is composed
of other parts, wait a second.
4:37
Well, anyways, before we get to fixing
this SRP issue, let's talk about the demo.
4:42
First off, Tex loved it.
4:48
He was slapping his knee and
tipping his hat, and
4:50
then he asked the question,
you sure this gonna work?
4:52
I was like, yeah.
4:55
And he goes, what happens if I
choose one of them empty bins.
4:57
Sure enough, he found a bug,
how'd I miss that?
5:02
Well for one, I was rushing, and
secondly, there are no tests.
5:05
We need tests.
5:09
On top of it,
would I have even tested that?
5:11
Remember, unit tests only test
public facing units of work.
5:14
All that choosing stuff is private,
so what is the solution here?
5:19
Oh, what if I did something like this?
5:24
We can keep the public facing stuff here
in the vending machine the same, but
5:26
if we make components like Chooser, you
know the way that we press the buttons?
5:30
And then also if we made
a thing like the Creditor,
5:34
you know the thing where
they put the money in?
5:37
They could still be encapsulated and
private inside the machine like this.
5:39
But their methods could be public.
5:44
Ah-ha, the best of both worlds.
5:46
The responsibilities are broken out,
and now they can be properly tested.
5:49
See how testing kinda forced us to follow
the single responsibility principle as
5:53
well as encouraged composition.
5:57
The machine is now composed
of testable parts.
5:59
So I told Tex, sorry for missing that.
6:03
I didn't have time to write test.
6:05
If I had more time I would have used
the test driven development approach.
6:06
TDD is a development practice where
you write tests before the code.
6:11
And actually the code will probably
look just like we're imagining, right?
6:15
Mainly because we'd have to test it.
6:19
We'll talk a little bit more
about TDD in this course, but
6:21
to truly learn how to do this properly,
it deserves a course of its own.
6:24
Check the teacher's notes for more info.
6:28
So our tiny plane landed and Tex says,
6:30
why don't you all work through getting the
proper test in place and give me a holler.
6:32
So I'll tell you what,
you're in a unit testing course and
6:36
you've been learning a ton, but
you haven't even seen a test yet.
6:40
Let's do something to fix that.
6:43
Why don't you let me fix the SRP problem
by using composition of different parts,
6:45
and you wrap up the exercise, and
we'll meet up and write the test together.
6:49
I'll show you how to test
right after this little break.
6:54
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