really nice weather to sit inside and do
a video hello function here’s a couple
of weeks back I made a video about how
to get your team to do unit testing in
one part of that video I talked about
how to do Maki and in today’s video I
would like to show you some more
down-to-earth examples showing how I do
mock it the title of this video says
that it is the best way to do mocking
but that is really a lie this is just
how I do mocking but I’ve had a lot of
success with it you will basically have
to judge for yourself if you think this
is a good idea or if you’re wrong yes
you have some sample code I created an
app to kill the lights in this room so I
have a bunch of Philips hue lights in my
home you can you can control them via
via app it’s really cool Hugh also has
an API which we’re gonna use today to
demonstrate some unit tests in mocking
you see I have this this big has white
lights in my face when I am recording
and when I when I am recording I want to
turn the you lights off to make the
lighting completely predictable so it
does switch around so today I have
created a little command-line utility to
do that quickly and this is how it works
I just write kill lights
it says not authenticated please press
the button on your bridge and run this
script again so I will have to go over
and press the button on that u bridge to
prove that I have physical access to the
bridge done now I just write your lights
again and now it’s authenticated and now
observe the lamp back that is the
entirety of the software so this little
API interacts with three things first
the hue API of course with the hue API
it creates a hue username which it saves
on the file system it also writes out
what it does to the console
we’re going to refer to the code that
does all these things as core and cooler
is what we’re testing core is the unit
in our unit test the console hue API in
file system is not what we are writing
tests for we’re assuming that they work
we’re collectively gonna refer to the
services that are around the core that
we’re not testing as the shell so let’s
have a little look at this little
project I put it up on github you can
find the link in this show description
before we start please note that this is
not a tutorial this is a sketch to
communicate an idea so don’t get caught
up in the details instead just try to
focus on the general idea so we have a
couple of files here we have tests
jeaious which is our unit tests we’re
gonna look at those in just a bit and we
also see core and Cheryl here let’s have
a look at the core first the first thing
that you’ll notice here is that there
are no required statements on top
instead all the things that the core
needs from the outside the hue API
define system console are injected here
in services services are the stuff that
lives outside of core in the shell if
you look here on line 3 you see that
we’re reading from a file this is just a
normal FS top read file but instead of
being required it is being injected as a
property on the services object and
that’s a general idea the rest of the
code in this file is not really
important so let’s have a look where the
service object is create the shell so
this is a shell what we see here is the
core being required and then we see the
FS and
known hue API and console just being set
as properties here on the services
object and the services object is just
being set here as an argument to the
core in a real non example app we would
probably have real arguments here being
passed on to the core but you will just
have to imagine that
and just quickly just to give you a
sense of the entire application this is
CLI job J S which is basically the
runner of the app the thing that runs
when you enter the kill killed
lights command and it just requires
shell and calls it that’s it of course
we do all this in order to make it easy
to knock out all the services in the
shell let’s take a look at test of Jas
first of all we require tape for the
test if you haven’t seen tape before
it’s just like it’s a test runner like
mocha only simpler we require Zenon Jas
if you don’t know what that is it’s a
mocking library we basically use it to
make fake functions that return fake
values easier and we require core
remember core is the unit that we are
testing in our unit tests we don’t
really care about the services in the
shell that’s somebody else’s problem we
care about how core interacts with those
services and that is what we’re testing
let’s walk through the press test here
on line 37 we are making the actual code
the core and we are passing in the
services as the service object which
we’re creating here on line 31 we have a
helper for this because we do it in
every test so let’s have a look at that
and create service stomps over here
great service stops just makes an object
that contains mock versions of the
services in the shell which sonam stops
instead of the real implementations here
notice here that we are only mocking the
things that we know are needed in the
tests the real FS library node has way
more methods than this but we only care
about these two because those are the
only ones being used by our code so
there is absolutely no need to make a
generic mock version of your objects
mocking it’s it’s time consuming and
hard so you should do it as little as
possible so let’s go back down to the
test
if you look here on line 35 this is
where we intercept the debrief vehicle
let me split that into two lines for you
here when core tries to read the
username stored on the file system it
will get an error here and then we
verified down here on line 41 that core
handles this error correctly and
responds to it by calling registered
user on the API and that’s it that’s the
pattern you separate your code into two
parts the core that is your unit that
you’re testing the logic that is
dependency free and then you have your
shell which is all the dependencies with
side effects and stuff and you inject
that in that way you can in your unit
test index a completely fake shell and
then it’s inspect the shell if the core
called it correctly every up is
different and I tend to write two
different tests in every hour right but
I tend to always come back to these core
and shell semantics I guess it’s because
it’s really easy to reason about and it
doesn’t have any weird magic it’s just
objects there are cast frameworks that
moc require statements and stuff like
that but that’s a lot of magic and I
don’t know I always get into trouble
when I use magic when programming I like
the simple core shell semantics core is
the unit that is being tested and you’re
testing that it interacts correctly with
the shell this whole thing as usual is
inspired by somebody a lot smarter than
me
Gary Bernhardt and his store boundaries
also linked below it’s pretty great you
have just watched an episode of fun fun
function a weekly show where we try to
become more excited and confident about
programming by exploring all the wisdom
wild ideas and having fun do not miss
out on the next episode subscribe until
next Monday stay curious you