Please don't mock me

The video above was recorded at the inaugural Assert.js 2018 conference in San Antonio, Texas.

If you’ve ever been frustrated with how a test faked out a network request, mocked something out, or continued passing while production burned, then this talk is for you. In it, I do my best to boil down nearly a decade of practicing test-driven development with JavaScript to summarize the Do’s and Don’ts of poking holes in reality when writing tests.

By watching this talk, you’ll learn about 9 abuses of mocks and 1 workflow that uses test doubles effectively—each explained at a level of detail you probably haven’t seen elsewhere. While you’re at it, you’ll also get a pretty good handle on how to use our testdouble.js library, as well.

If you enjoy the talk, please share it with your friends and colleagues! And if you know a team that could use additional developers and is looking to improve its JavaScript craft, we’d love to hear from you.

00:00

(applause)

00:03

- Hello. Alright, let's get rolling.

00:07

The title of this presentation is

00:08

"Please Don't Mock Me."

00:09

That's what my face looked like seven years ago.

00:12

I go by my last name Searls on most internet things.

00:16

If you'd like my contact info,

00:17

you could npm install me.

00:19

(laughter)

00:21

I am the creator and the current maintainer

00:24

of the world's second most popular

00:25

JavaScript mocking library,

00:27

if you don't count Jest's mocks or Jasmine spies.

00:31

Here's a download chart.

00:33

That's sinon.js, the most popular,

00:35

and that's us down there.

00:36

(laughter)

00:37

This was a really important day.

00:40

We finally caught up last month,

00:41

but then npm turned the servers back on.

00:44

(laughter)

00:46

So we're fighting. (laughter)

00:48

You can help boost our numbers

00:50

by installing testdouble.

00:51

That's the name of the library today.

00:54

and playing with it.

00:55

We're gonna see a bunch of examples of it today.

00:56

And the reason I'm here is to tell you

00:58

that the popularity of a mocking library doesn't matter

01:01

(chuckles)

01:02

And of course you should respond by saying,

01:04

"You're just saying that because your thing's not popular."

01:06

(laughter)

01:07

And that's probably true. (laughter)

01:09

And I'm rationalizing a bit here.

01:13

But really the reason that I'm saying that

01:16

is because literally nobody knows how to use mocks.

01:19

And that's shocking.

01:21

I probably shouldn't say that.

01:22

I should say figuratively nobody knows how to use mocks.

01:26

And the reason kind of comes down to this Venn diagram.

01:30

Because there is a group of people

01:31

who can explain how to best mock things,

01:34

and then there's another group

01:35

who always mocks things consistently.

01:37

But unfortunately, there's a much larger universe

01:40

of people who use mocking libraries.

01:42

And I wasn't aware of this,

01:44

because when we designed testdouble.js,

01:45

it was really just targeting the intersection

01:47

of people who know how to use --

01:49

fake things well in their tests.

01:52

And it's a small group of people.

01:53

So just becoming more popular

01:55

doesn't actually solve any problems.

01:57

So instead our goal, in both writing the library

02:01

and its messages and its opinionated documentation,

02:03

as well as this conversation itself,

02:05

is to grow the intersection of people

02:07

who know how to use mock objects well,

02:08

so that they can write better designed code

02:10

and better designed tests.

02:12

But before we dig in, we need to define a few terms.

02:14

First, subject or subject under test.

02:17

Whenever I say this, imagine your performing an experiment

02:20

and this is your test subject.

02:22

The thing you're testing.

02:24

Dependency I'm gonna use to define anything

02:26

that your subject relies upon to get its job done,

02:30

usually it's another module that it requires.

02:32

Unit Test. This is a loosey goosey term

02:35

that has lots of definitions,

02:36

but for today, we're just going to say

02:38

that a unit test is anything that exercises

02:40

a private API by invoking a method,

02:43

whether or not it calls through

02:44

to its real dependencies or not.

02:46

Test double is a catch-all term

02:49

that just means fake thing that's used in your test.

02:51

It's meant to evoke the image of a stunt double

02:53

like for the purpose of a test instead of a movie.

02:56

So whether you call them stubs or spies or mocks or fakes,

02:59

for the purpose of this conversation,

03:00

it doesn't really matter.

03:01

Also, oddly enough, I come from a company called Test Double

03:05

We are a consultancy.

03:06

We pair with teams that are probably just like your team,

03:10

if you're looking for extra software developers.

03:11

We'll deploy, work with you, get stuff done.

03:14

But also with any eye to, you know, making things better.

03:16

You can learn more about us at our website.

03:18

And part of the reason I like

03:21

that we named the company Test Double

03:22

is that something about mocking is an evergreen problem,

03:25

because it sits at this intersection

03:27

of communication, design, technology, testing.

03:31

All of these different concerns,

03:32

they need to be sorted out among every single different team

03:35

and so it's never like it's gonna truly be solved.

03:37

It's something we can keep on working and getting better at.

03:40

Of course, I did not think very hard

03:42

about creating a library and a company with the same name

03:44

and the brand confusion that would result.

03:46

So I've had a few people stop me and ask,

03:48

"Do I really have 30 full-time employees

03:51

"who just work on a mocking library?"

03:52

And an unpopular one at that.

03:54

The answer is no.

03:57

We're consultants.

03:59

And there's gonna be lots and lots of code examples

04:01

in this talk today, but there's no test at the end.

04:03

They're just here for illustrative purposes.

04:06

I don't expect everyone to follow

04:08

every single curly brace and semi-colon.

04:10

Also, there's no semi-colons because I use standard.

04:13

(laughter)

04:15

And I'm also here --

04:16

If you're a pedant like me, I'm going to be

04:18

very lazily using the word mock

04:20

for situations that like mock isn't technically

04:23

the correct word if you're into jargon.

04:25

It's just monosyllabic and popular.

04:27

So I'm gonna be saying mock a whole lot.

04:29

Alright, this presentation has four parts.

04:31

The first part is obvious abuses of mock objects.

04:34

Then we're gonna move into the slightly less obvious abuses.

04:37

Then we're gonna talk about rational use cases

04:39

for mocking stuff but nevertheless dubious.

04:42

And then finally, the only real good use

04:45

that I found after a decade of doing this.

04:47

And so let's just start off,

04:49

top to bottom, with the obvious abuses.

04:52

And talk about partial mocks.

04:54

So let's say that you run a park ticket kiosk,

04:57

and people tap on the screen

04:59

so that they could order tickets.

05:00

And say that it's a 12 year old who calls.

05:03

We call through to our inventory

05:05

to ensure that we have child tickets

05:06

available before we sell them.

05:08

If the person had said they were 13,

05:09

we'd call back to the inventory

05:10

to make sure we have adult tickets.

05:12

And then, either way, regardless of the age you type in,

05:14

we want to try to upsell them to Express Passes.

05:17

And so we ensure that we have those available.

05:18

The logic for this might look

05:20

like something like this as a function.

05:22

If they're less than 13, we'd call the child ticket function

05:24

If it's over, call the adult.

05:26

And then if the express modules turned on,

05:28

we'd call that.

05:30

And then the rest of your purchasing flow.

05:32

Now how to test this, well you'd probably think

05:34

I'll create a kiosk test module.

05:37

I'll invoke it just like I always would.

05:39

Then I've got this call to inventory,

05:41

but this method doesn't return anything.

05:43

It doesn't have any other measurable side effect,

05:46

and so what I'll do is I'll mock it out.

05:47

And then I'll just verify that

05:49

the call took place how I expected.

05:50

You could do that in a test like this.

05:52

You could replace that method out of the inventory,

05:54

and then have the test just pass in

05:57

12 year old and then verify

05:59

that the ensureChildTicket was called one time.

06:02

To do the adult code path,

06:04

you would just do the basic same thing,

06:05

punch a hole in reality.

06:07

While you're there, you could make sure

06:09

that you don't call the adult ticket

06:11

during the child code path,

06:12

and then everything else is copy paste,

06:14

but with changed values.

06:15

Change the age, and make sure it's calling adult

06:17

instead of child, and so forth.

06:18

Pretty perfunctory.

06:20

You run the test.

06:21

The test passes.

06:22

Everything is great.

06:23

Problem is, time passes,

06:25

and as time passes, you get a phone call,

06:28

because the build is broken.

06:29

Your test is failing.

06:31

So you run the test again,

06:32

and sure enough, it's failing,

06:33

and it's failing in a weird way,

06:34

where the child code path is calling

06:36

the adult ticket checker thing,

06:38

and the adult one is calling it twice.

06:40

So you don't know what's going on,

06:42

you open up the code,

06:43

and you look and try to understand it,

06:44

and you realize the only other

06:46

potential cause for this is

06:49

this call to ensure Express Pass.

06:51

So you open up that inventory.js,

06:53

but remember we faked out two of these functions,

06:55

but not all of them.

06:57

And so this ensure Express Pass is still the real thing,

07:00

and it looks like somebody changed it

07:01

to make sure that they don't try to upsell the Express Pass

07:03

if the adult one's not available.

07:05

And so like you can't really --

07:06

who's to blame in this case, right?

07:08

You can't really blame the person maintaining this

07:09

for having not anticipated somebody would have

07:12

a half-real, half-fake inventory

07:13

floating around their tests.

07:15

And so what do we do, right,

07:18

when we hit this situation.

07:19

Well, one thing you can do, that's just a quick fix,

07:22

is to also just punch a hole

07:23

in that ensure Express Pass thing,

07:25

and doing nothing more than that will make this test pass,

07:28

but it doesn't quite feel right.

07:30

Sort of like the advice is when your ship is sinking

07:32

to just keep poking holes until it stops.

07:34

(audience laughs)

07:35

Something is wrong fundamentally with this design,

07:39

and the problem is, it's only superficially simple.

07:42

It feels simple because the text in that test

07:44

is only concerned with what we care about,

07:46

but it's not actually forming a good experimental control.

07:49

So instead, I'd knock all that out,

07:51

replace the whole inventory module,

07:53

and then require the thing that I depend on.

07:55

That way I know that it's not going

07:57

to change for nonsensical reasons.

07:59

So in general, rule of thumb,

08:01

if your dependency is real,

08:03

and you're calling a thing with the test,

08:05

it's gonna be really easy,

08:06

'cause then we're invoking it just like we always would.

08:08

If the dependencies are fake,

08:10

then it's still pretty straightforward,

08:12

because mocking libraries are pretty sophisticated.

08:14

But if you have a dependency

08:15

that's simultaneously real and fake,

08:17

that's when you start to get feedback

08:18

like what's being tested,

08:20

or what's the value of the test here.

08:21

It's just a bad time, don't do it.

08:23

There's a special sub-type of partial mocking,

08:26

called mocking the subject,

08:27

and long story short, I'm just exhorting people

08:30

please don't fake parts of the thing that's being tested.

08:34

And like, you should laugh, and be like that's funny.

08:36

Why would you fake out the thing that you're testing?

08:37

That doesn't make any sense.

08:38

But people do it so much

08:40

that I've had to name a pattern after it

08:42

called contaminated test subjects.

08:44

And I get a lot of issues opened about this.

08:45

Typically, the report, or rhetoric, that somebody has to me

08:49

to say I've got a good reason for this is.

08:51

Oh this module is so huge

08:54

that I've gotta fake out this thing and this thing

08:55

in order to test this other thing.

08:57

But it's sort of like, well,

08:58

if you're thing is too long,

08:59

poking holes in it all over isn't gonna make it shorter.

09:02

Now you just have two problems.

09:04

You've got a big object that nobody understands,

09:06

and tests of it that nobody trusts.

09:08

So I don't have anything more to say here.

09:10

Just don't do that.

09:11

A third obvious abuse of mock out tests.

09:14

Replacing some, but not all, of your dependencies.

09:17

Some people use the term overmocking

09:21

as if mocking is a thing like an affordance to be moderated.

09:24

It makes me think that there's

09:26

like this invisible mockometer or something.

09:28

And as you mock stuff, it starts to fill up,

09:32

but be careful, because it might blow up.

09:33

And now you've overmocked,

09:34

'cause you crossed this invisible threshold.

09:36

It just makes no sense to me,

09:39

and to explain why, we're gonna take an example.

09:41

Say that you handle seat reservations,

09:43

and so you're pair programming,

09:45

and in your set-up, you think

09:47

for this thing that requests seats,

09:49

I need a seat map, something to price the seats,

09:51

to tell whether they're vacant,

09:53

and then finally to make the booking request.

09:55

And so, that's what our set-up looks like,

09:57

and I imagine you have different test cases,

10:00

like the seat's open or taken or expensive and yada yada.

10:03

And so because you're pairing

10:04

you gotta normalize on approach,

10:06

and the person on the right prefers writing

10:08

isolated uni-tests that mock out all of their dependencies.

10:10

The person on the left just wants maximally realistic tests

10:13

to make sure that things work,

10:14

and wants to avoid mocking.

10:15

And since you're pairing, what do you do?

10:17

You compromise,

10:18

and so you just flip a coin, and then you just

10:19

mock out half the things, instead of all of them.

10:21

(audience laughs)

10:23

I get it. That's not a laugh line.

10:24

That happens all of the time.

10:26

But you know, you check your mockometer,

10:28

on this whole overmocking ideology,

10:30

and you're only at 47 percent.

10:31

Looks okay. (audience laughs)

10:34

It just snuck in there.

10:37

Time passes, and you get a call again,

10:39

'cause the test is failing.

10:41

What's happening here is that

10:42

this request seat function that's the thing under test,

10:45

is calling a map to get a seat back.

10:47

Normally it gets that seat,

10:48

but it's not anymore because the format of the string

10:51

is now, instead of 23A, it's 23-A.

10:54

Nobody called us, so our test started failing.

10:56

Now, that person on the right

10:57

who prefers to isolate their subject might say,

10:59

"This failure had nothing to do with the subject."

11:01

And she'd be right.

11:02

'Cause if you look at where seat number is here,

11:04

it's just simply passed to this other thing.

11:06

There's no logic or string stuff here.

11:08

And it's the dependency that should be dealing with that.

11:11

This test shouldn't necessarily have broken.

11:13

So she fixes it, per se, by going into that require,

11:16

and then just knocking it out with a fake,

11:18

and updating the test, and getting it's passing again.

11:20

Now more time passes,

11:22

but this time production is broken.

11:24

And what's happening in this case is that

11:26

book seat dependency that would pass the itinerary,

11:28

the seat, the price tier to actually make the booking.

11:31

That's faked out, and it turns out that the person

11:34

who maintains that transposed the second and third argument,

11:37

and now it's price and then seat in that call order,

11:40

but again, nobody called us.

11:42

And this time, our test is still passing,

11:43

because the test didn't enforce

11:45

the errity of that particular method.

11:47

And so now production blew up

11:49

because no test was there to catch it.

11:51

And of course now the developer on the left

11:52

who likes to have tests be as realistic as possible,

11:55

will say, "Well, this wouldn't have happened

11:56

"if we hadn't mocked book seat."

11:58

And he's right, too.

11:59

So if we look at this here,

12:01

sure enough we're calling book seat

12:02

with the incorrect argument order.

12:06

There it is right there.

12:08

And he's upset, so he goes in

12:09

and looks at where we've mocked out book seat,

12:11

and replaces it with the real thing.

12:13

I'm pretty sure this isn't what people mean

12:17

when they say ping-pong pairing,

12:19

but it's the kind of passive aggressive back and forth

12:23

that I see in code bases all the time,

12:25

when people can't agree on a common approach

12:27

to known situations.

12:29

The funny thing about it is that tests are supposed to fail.

12:34

If a test never, ever fails

12:35

in the thousands of times that you run it,

12:37

that test has told you effectively nothing.

12:39

So we should plan for that failure

12:42

by designing how things should fail.

12:45

Like take a wired unit test, for example.

12:47

This one calls for all of its dependencies.

12:49

Nothing is mocked.

12:50

Our mockometer readings are safe.

12:52

And you ask when it should fail,

12:55

well, the test should fail whenever

12:56

its behavior or its dependencies' behavior changes,

12:59

and as a result of that, we need to be careful

13:02

and cognizant of the amount of redundant coverage

13:05

across all of our tests to reduce the cost of change.

13:08

For example, if one of those dependencies is required

13:10

by 35 other things and then you need to change it,

13:12

now you've got 35 broken tests.

13:14

That's kind of a pain.

13:15

Now in an isolated unit test,

13:17

you have the opposite situation,

13:18

where all of your dependencies are mocked out,

13:20

and it's 100 percent mocked out,

13:22

so people are flipping out 'cause it's so overmocked.

13:24

Readings are off the charts.

13:26

And you ask, when should it fail?

13:27

Well that test in particular is gonna fail

13:29

when the dependencies' protocol changes.

13:31

When the contract or the relationship

13:32

between the caller changes.

13:34

And so, to be safe, you should create

13:37

some kind of integration test that just ensures

13:39

that everything's plugged in together correctly.

13:41

That's typically all you need, but you do need it.

13:43

But what about this test,

13:44

where things are half real and half fake.

13:46

Well, from the overmocking ideology perspective,

13:50

it's safe, it looks fine.

13:52

But you ask, when should it fail,

13:54

and the answer is anything could change and break this test.

13:58

And so therefore, we should not write tests like this.

14:01

(audience laughs)

14:01

So please don't do this.

14:03

So instead of critiquing how much somebody is mocking,

14:06

critique how mocks are being used and for what purpose,

14:08

and start to get into the actual strategy behind a test.

14:12

The common thread between all these obvious abuses

14:14

is that it's clear people tend to --

14:17

We have an intrinsic default setting

14:19

to value maximal realness over experimental control.

14:23

I really like this quote.

14:25

"Instead of treating realness as a virtue to be maximized,

14:29

"we should clarify what our test is trying to prove

14:31

"and then use all of our tools, mocks included,

14:34

"to ensure we have sufficient experimental control."

14:37

Unfortunately, that quote was me, just now.

14:39

(audience laughs)

14:41

I wish somebody had told me this years ago.

14:44

So let's move on to the less obvious abuses.

14:46

And mocking out third party dependencies.

14:49

This is a frequent request on our --

14:54

GitHub issues.

14:55

So let's say you depend on this third party dependency

14:57

in your application called awesome-lib.

14:59

And it's so awesome, that references to it

15:01

have leaked all throughout your code base.

15:03

And the usage of it is a little bit strange though.

15:06

First, you call it.

15:07

It takes in the config file,

15:09

which you'll read from disc.

15:10

And then it returns an instance with this optimize method

15:12

and a call back, and then you get these

15:14

cool interpreter hints that make your code go fast, I guess.

15:17

Problem is, that's a really weird usage of the library,

15:21

and so it's really hard to mock out.

15:23

Awesome lib, it's really painful.

15:24

Here you can see, we have to replace the whole file system.

15:27

And then we replace the module itself.

15:29

Then we have to create an instance that the lib will return,

15:33

and then we have to do all this stubbing.

15:34

And we say, like oh, well

15:35

when the file system has this path, it gets this config.

15:38

When that config is passed to awesome lib,

15:39

it returns that instance, and then finally,

15:41

when we call that optimize method on the instance,

15:42

then we get a call back trigger that passes back the hint.

15:46

That's a lot of work.

15:47

And it's easy to look at that,

15:50

'cause it's a lot of test set-up,

15:51

and it says "td" everywhere.

15:53

It's easy to look at that and blame the mocking library,

15:55

but really the root cause is the design of the code.

15:58

So, hard to mock code is hard to use code, typically,

16:01

but because we're staring at the test,

16:02

we tend to blame the test.

16:05

So that ping just sort of kind of

16:06

festers throughout our code base.

16:08

We got a lot of messiness in our code,

16:09

but also a lot of duplication in our tests.

16:11

And so maybe this'll save us,

16:13

but there's been an announcement

16:14

that awesome lib 2 is coming out,

16:16

and so you're excited, like maybe this will make it easier.

16:18

But of course, all they did was

16:19

change the call backs to promises.

16:21

(audience laughs)

16:23

So you gotta update all those references.

16:25

And now, you like check it out.

16:27

Instead of stubbing returns and callbacks,

16:28

you gotta change those to resolve.

16:30

And then you gotta do it 18 different places,

16:32

which is frustrating.

16:33

And assault on wounds, HackerNews calls,

16:36

and nobody uses awesome-lib anymore.

16:39

Instead, everyone uses mindblow now.

16:42

And so, your team goes from frustrated to angry,

16:46

and just watching the churn of these third dependencies

16:49

go through your system.

16:50

So TLDR, if something is hard to mock

16:54

and you own that thing, it's a private module

16:56

with its on API that you can change,

16:58

the remedy is change it.

17:00

That test has provided you with valuable feedback,

17:02

saying the design of this thing's hard to use.

17:05

But if you're mocking a third party thing,

17:06

and it's painful to mock,

17:09

well what do you do then?

17:11

Send a pull request.

17:12

You do nothing.

17:13

It's just useless pain,

17:15

and useless pain, if everyone here cares about testing,

17:18

you came to a conference just about JavaScript testing.

17:20

If your team is suffering a lot of useless pain

17:23

in their testing workflow,

17:24

other people are gonna notice.

17:26

That's money going out the window,

17:27

and you're gonna lose credibility

17:28

and political capital to keep on testing.

17:31

So we should try to minimize it.

17:32

So instead of mocking out third party dependencies,

17:35

I encourage people to wrap them instead

17:37

in little custom modules that you do own.

17:40

This is a module that wraps awesome-lib.

17:43

It kind of tucks under a rug almost

17:46

all of the complexity and how to call it.

17:49

Instead, you get this simple little call back API.

17:52

And as you think, you realize now you have breathing room

17:54

to consider how we use this thing.

17:56

You realize we could probably cache that file read,

17:59

'cause there's just a single place that's using this,

18:01

but we crammed it in in the interest of terseness

18:03

as we copied that third party reference everywhere.

18:06

Or maybe it's got certain errors we understand

18:09

that we could handle or at least translate

18:10

into something more domain specific.

18:12

The tests obviously get a lot easier,

18:14

because we're gonna depend on that wrapper

18:16

and mock that out.

18:18

So we can delete all this,

18:19

and then this stuff gets a little bit simpler, too.

18:21

And just creates a lot more space and breathing room

18:25

to consider (audience laughs) the design

18:27

of what you actually care about which is the subject,

18:30

instead of all this cognitive energy going to test set-up.

18:33

You don't need to worry about

18:35

writing unit tests of your wrappers.

18:37

Trust the framework.

18:38

They probably work.

18:39

You definitely don't want them to be isolation tests,

18:41

because then if they are hard to mock,

18:43

you're gonna have that useless pain again,

18:45

which is just money out the window.

18:46

Another thing that I see people do

18:49

that isn't obviously a problem,

18:51

but usually turns out to be one,

18:52

is when they tangle up logic

18:54

with their delegation to dependencies.

18:56

And so, let's take an example.

18:58

Let's say you own a fencing studio,

18:59

and you rent out swords.

19:00

But you might want to be able to ask,

19:03

"Hey, how many swords do we expect

19:04

"to have in stock next Tuesday?"

19:06

And you could write a function for that.

19:07

So you pass in a date.

19:09

You call something to fetch rentals,

19:11

and that gets you a call back with the rentals

19:12

that are currently outstanding.

19:13

And then you need to filter them down,

19:15

so you take the duration of days,

19:18

and get it into milliseconds,

19:19

and then you add that to the start time

19:21

to figure out when they're due.

19:23

And then if they're due before the given date,

19:24

you can expect the rental to be due at that point.

19:28

And then you just pluck the swords out of that.

19:29

In addition, you have current standing inventory,

19:32

so you call your inventory module,

19:34

which gives you a call back,

19:35

and you just concatenate that inventory

19:38

with the swords that you expect to be back.

19:39

So it's pretty straightforward.

19:40

We can run a test of it.

19:42

Start by creating a rental object.

19:44

It has like -- we'll stub fetch rentals

19:47

to return a rental to us.

19:49

We'll stub the current inventory

19:50

to return a leased sword to us.

19:52

We'll call it with the correct date so they all match up,

19:55

and then we'll just assert

19:56

that we get those two swords back from the function.

19:58

This test passes.

19:59

That's great.

20:01

So time marches on yet again.

20:03

This time, your test didn't break,

20:04

but rather somebody points out,

20:06

"Hey, this current inventory thing with the call back

20:08

"can make this faster now,

20:09

because we have a new inventory cache,

20:11

which is synchronous."

20:13

And so she jumps into the code,

20:14

and deletes that call back method.

20:15

Instead it just calls the synchronous one,

20:17

out those things.

20:18

And things are a little bit cleaner now,

20:19

a little tidier, and definitely a lot faster.

20:22

But of course, it broke the test.

20:23

And that's really frustrating.

20:25

You look at the test.

20:26

Here it is, the test is specifying

20:27

that it relies on current inventory.

20:30

And some guy on the team shows up,

20:33

"Oh, this test is coupled to the implementation,

20:36

"and that is very bad, and we should feel bad."

20:38

Those scare quotes are mine,

20:39

because I think it misdiagnoses

20:42

the real root cause problem here,

20:44

which is that we have this naive assumption

20:47

that tests exist to make change safe,

20:49

but we rarely really inspect in our minds.

20:53

What kind of tests make

20:55

what kind of change what kind of safe?

20:58

And the answer is different depending

20:59

on the type of test that we're running.

21:01

So let's dig in.

21:02

First, if you're running a test of something

21:04

that has no dependencies, no mocking at all,

21:06

it probably specifies logic, ideally a pure function.

21:09

And if it does, that means if the logic's rules change,

21:12

then the test needs to change.

21:14

So take for example, you convert a for loop to a four each,

21:17

that calls on duration.

21:18

That's just a refactor.

21:19

It's probably not gonna change the behavior.

21:21

The test should keep passing.

21:22

But if we're changing the duration

21:24

to some duration plus a one day grace period,

21:26

you should absolutely expect that test to fail,

21:28

because you just changed the rules of the game,

21:30

and the test's job was to specify those rules.

21:33

Consider the case of writing a test of something

21:35

with mocked out dependencies,

21:36

the test's job there isn't to specify logic,

21:40

but it's to specify relationships.

21:41

How is this subject going to orchestrate this work

21:45

across these three things that actually go and do it?

21:47

And so when the contract between it

21:49

and the things it depends on changes,

21:51

that's when the test needs to change.

21:53

So if this duration grace period thing happens,

21:55

that test should keep on passing,

21:57

because that should be implemented

21:58

in something responsible for actually doing the work.

22:00

But if we start calling inventory cache

22:03

instead of current inventory,

22:04

of course you should expect that to change,

22:06

because the relationships in the contracts are different.

22:08

So where things fly off the rails is when somebody asks

22:11

what if the subject has both mocked dependencies and logic?

22:15

Well, to graph out our current situation,

22:18

we have this sword stock module,

22:19

which depends on current inventory and fetch rentals,

22:21

but it also has this third responsibility

22:24

that it just brings in house,

22:25

which is to calculate when swords are due.

22:27

And so, this first one specifies a relationship.

22:30

The second one, it's specifying relationship.

22:32

But the third responsibility,

22:34

it's implementing this logic itself.

22:36

And you can see this really clearly in your test, right?

22:39

This stuff's focused on relationships.

22:41

This stuff's focused on logic.

22:42

Same thing in the code.

22:44

This stuff, relationships.

22:46

This a big old chunk of logic.

22:48

And what it represents is a sense

22:50

mixed levels of abstraction,

22:52

where two thirds of our thing is concerned about delegating,

22:54

and one third is concerned with logic,

22:57

which is a classical design smell.

22:59

And we just got to find out about it,

23:00

because we were mocking.

23:02

So what I'd recommend you do,

23:03

spin off that third responsibility

23:05

so that sword stock's only job

23:08

is to be a delegator of responsibility to other things,

23:11

and trust me, you'll feel better.

23:12

And on top of it, swords due taking in a date and rentals

23:15

and returning swords, is now a pure function,

23:18

and your intuition will start to agree with you

23:20

as to when it should change, and when it shouldn't.

23:22

And what kind of safety you're gonna get from it.

23:24

So in short, if a test specifies logic,

23:27

it makes me feel great, 'cause there's nothing easier

23:29

to test than passing in a couple values

23:31

and getting one back.

23:32

If a test specifies relationships,

23:34

I feel good because I've got some sort of evidence

23:36

that the design is being validated,

23:39

that thing's are easy and simple to use,

23:40

but if a test specifies both,

23:42

I feel no safety whatsoever from it.

23:46

I'm just bracing for the pain of a hard to maintain test.

23:49

So if you struggle with this, or if your team does,

23:52

and you need some slogan to tape to a wall.

23:55

Have it be this one.

23:56

That functions should do or delegate, but never both.

24:00

I think a lot of our designs could improve

24:02

if we followed that.

24:03

Another less obvious abuse is

24:06

when people mock data providers

24:08

at intermediate levels in the stack.

24:10

So let's say, hypothetically,

24:12

that we invoice travel expenses,

24:13

and we have an invoicing app that calls via HTTP

24:16

to an expense system, we get some JSON back.

24:18

And so our subject under test sends these invoices,

24:21

the system's way over there though,

24:23

because we depend on building invoices,

24:25

which depends on filtering approved expenses,

24:27

which depends on grouping them by purchase order,

24:30

which depends on loading the expenses,

24:31

which depends on http.get,

24:33

which finally calls through to the other system,

24:35

and then of course we get all the data

24:36

transformed all the way back up the stack.

24:38

And so, when you have this layered of an architecture,

24:41

it's reasonable to ask, "Okay, so what layer

24:42

"am I supposed to mock when I write my test?"

24:44

Well, it depends.

24:46

If what you're writing is

24:47

an isolated unit test of said invoice,

24:49

then you always want to mock out

24:50

the direct dependency because it's gonna specify

24:53

the contract that you have with it,

24:54

and the test data that you need

24:55

is gonna be absolutely minimal to just exercise the behavior

24:58

and the subject that you're concerned with.

25:00

But if you're trying to get the regression safety

25:02

and make sure that the thing works,

25:03

then you either want to keep everything realistic

25:06

or stay as far away as possible.

25:08

Ideally, out at the http layer,

25:10

because those fixtures that you save off,

25:12

can have some kind of meaning later on if anything changes,

25:15

and you can use that to negotiate

25:16

with whoever's writing the expense system.

25:18

What you don't want to do is just pick some arbitrary depth,

25:22

like this group by PO thing and mock that out.

25:25

Maybe it's the nearest thing, or maybe it feels convenient,

25:27

but it's gonna fail for reasons

25:29

that have nothing to do with send subject, send invoice.

25:32

And the data at that layer is this internal structure

25:36

that doesn't mean anything outside of our system.

25:39

So if the mock layer is a direct dependency

25:41

and it fails, it's a good thing,

25:44

because it means that our contract changed,

25:45

and we need to go and inspect that.

25:47

If the mocked layer is an external system and it blows up,

25:50

it's another good failure,

25:51

because it's the start of a conversation

25:53

about how this API's contract is changing underneath us.

25:56

But if you mock out an intermediate layer,

25:59

again it's another form of useless pain,

26:01

you learn nothing through the exercise,

26:02

except that you had to spend half a day fixing the build.

26:05

The common thread between all these lesser abuses

26:08

of mock objects is that

26:10

through un-careful, undisciplined use of mocks

26:14

we undercut our test's return on investment.

26:17

Where we're just not clear about

26:19

what the value of the test is anymore.

26:22

And if you can't defend the value of your tests --

26:25

Excuse me, we can't defend the value of our tests

26:29

if they fail for reasons that don't mean anything,

26:31

or have to change in ways that we can't anticipate.

26:35

Unfortunately, that's also me,

26:36

because there aren't that many quotes about mocks.

26:40

(audience laughs)

26:40

Out there, it turns out.

26:42

Alright, I got my own quote wrong,

26:45

and how I read it, too.

26:46

(audience laughs)

26:47

Alright, so let's move on to the rational uses

26:50

that are often dubious in my opinion.

26:54

The first is when you use mocks in tests of existing code.

26:57

So let's say that you work

26:58

at an internet of things doorbell start-up.

27:01

And because you're a start-up, you move fast and loose.

27:04

You've got a lot of spaghetti code,

27:05

that you wish you could clean up.

27:07

But you just won more funding,

27:09

and so now you're excited.

27:10

You can finally start writing some unit tests.

27:12

You've been putting this off forever.

27:13

And it's been hanging over your head for a long time,

27:16

but you've got zero test coverage.

27:18

So you write what you think is gonna be

27:20

the easiest test that you could ever write.

27:22

It's just like pass the doorbell

27:24

to the thing that rings the doorbell

27:25

and increments like a ding count.

27:27

Here we go, we require our doorbell.

27:30

We require the subject that rings it.

27:32

We create a doorbell.

27:33

We pass it to the subject,

27:34

and then we should assert

27:35

that the doorbell's ding count goes up to one.

27:38

Great. Couldn't be easier.

27:39

So we run our test,

27:40

and of course, it fails.

27:41

And it says, "Oh by the way,

27:42

"doorbell requires a door property."

27:45

Well, okay, we can go in, require a door,

27:47

create a door, pass it to the doorbell, run our test again.

27:50

Oh, right, well you can't have a door

27:52

if you don't have a house.

27:53

Alright, fine, so (audience laughs)

27:55

we'll import a house, create a house,

27:56

pass it to the door, pass to the doorbell,

27:58

which passes to the subject, and run our test.

28:00

(mumbles) House requires a paid subscription,

28:03

and now we're talking about payment processes, databases.

28:05

This code was not written to be used more than once.

28:08

It was just used once in production.

28:10

So it's not very usable.

28:11

And so we run into this pain of all this test set-up.

28:13

So a lot of people here will look at this,

28:16

they'll table flip, they'll delete all that stuff,

28:17

and they'll just replace it with a mock object.

28:19

Something fake that they can control

28:21

for the purpose of just getting a test to run.

28:23

And they'll set the ding count to zero.

28:25

They'll tuck it all in.

28:26

And clearly that smells.

28:28

And if you're not --

28:30

If you're mocking smell-o-meter is not finely attune,

28:34

the nature of this smell is actually really subtle,

28:37

because every other example that I've shown

28:39

so far of a mock in a test is replacing

28:42

a dependency of the subject that does part of the work

28:44

that the subject delegates to,

28:46

not a value that passes through it,

28:48

either an argument or a return value.

28:50

The reason for that is values

28:52

carry type information which is useful,

28:54

but also that they should be really cheap and easy

28:57

to instantiate free of side effects.

28:59

So if your values are hard to instantiate,

29:00

it's easy, just like make 'em better.

29:03

Don't just punch a hole in it, and mock 'em out.

29:06

And so nevertheless, you got that test going.

29:09

You got a little bit of tests coverage.

29:10

Another I've seen teams do is

29:12

if they've got a really big, hairy module,

29:15

they'll want to tackle that first

29:17

when they start writing tests,

29:18

and so they want to write a unit test,

29:19

and if they try to write it symmetrically

29:21

against the private API of this thing,

29:23

it tends to just result in a gigantic test

29:26

that's every bit as unwieldy as the module was,

29:29

and gets you absolutely no closer

29:30

to cleaning that huge module up

29:33

and making the design better.

29:34

'Cause if you depend on 15 different things,

29:37

like whether or not you mock those dependencies out,

29:40

you're gonna have a ton of test set-up pain.

29:42

It's gonna be really hard to write that test.

29:44

And the underlying test smell was obvious --

29:46

or the smell rather, was obvious

29:48

before you even started writing the test,

29:50

which was like this object was too big.

29:52

And so if you know that the design has problems,

29:54

what more is a unit test going to tell you,

29:57

except be painful.

29:59

So instead, odds are the reason you're writing tests,

30:02

is like you want to have refactor safety

30:05

so that you can improve the design of that thing.

30:07

So if you're looking for safety,

30:08

you need to get further away

30:09

from the blast radius of that code,

30:10

increase your distance.

30:12

The way that I would do that is

30:13

I'd consider the module in the context of an application.

30:16

Like there's other complexities, sure,

30:17

like maybe there's a router in front of it or something.

30:20

But go create a test that runs in a separate process,

30:22

but then invokes the code the same way a real user would

30:24

by maybe sending a post request.

30:26

And then you could probably rely on it

30:30

going and talking to some data store of something.

30:32

And after you've triggered the behavior

30:34

that you want to observe,

30:35

maybe you can interrogate it with additional HTTP requests,

30:37

or maybe you can go and look at the SQL directly.

30:40

But this provides a much more reliable way

30:43

for creating a safety net to go

30:44

and aggressively refactor that problematic subject.

30:48

And so integration tests, they're slower.

30:50

They're finickier.

30:51

They're a scam, in the sense that

30:53

if you right only integration tests,

30:55

your build duration will grow in a super linear rate

30:58

and eventually become an albatross killing the team.

31:00

(audience laughs)

31:01

They do provide refactor safety,

31:04

so in the short and the medium term,

31:05

if that's what you need, that's great.

31:07

And plus, they're more bang for your buck anyway.

31:09

When you don't have a lot of tests,

31:11

you'll get a lot of coverage out the gate.

31:12

Another thing I see people who have existing code

31:15

that they're trying to get under test

31:16

and using mock objects,

31:17

they'll use mocks just as a cudgel

31:20

to shut up any side effects.

31:21

So you might see something like this.

31:22

Init-bell is being knocked out whenever we require init,

31:26

which is the thing responsible for starting up the app,

31:28

and somebody might point out,

31:30

"Hey, why are we faking this?"

31:31

And turns out, oh well, it dings every doorbell

31:33

some start-up chime sequence at require-time.

31:36

Now, that's a smell, right?

31:38

The root cause is -- a good module design

31:40

is free of side effects and item potent

31:42

and you can require the thing over and over again,

31:44

but because we didn't have any tests,

31:45

we kind of got into the habit

31:47

of having all these side effects everywhere,

31:48

'cause everything was only required by one thing.

31:50

So like, again, root cause, write better modules.

31:54

Don't just knock out reality left and right in your test.

31:56

So unless you're open to the idea

31:59

that writing isolated unit tests

32:01

is going to inform your design,

32:02

and that you're going to improve your design as a result,

32:04

don't even bother writing them.

32:06

Write some other kind of test.

32:08

Another rational use, but dubious one,

32:11

that I see a lot is when people use tests

32:13

to facilitate overly layered architectures.

32:17

One thing that I've learned in like lots of years

32:20

of test writing, development testing,

32:22

is that people who write a lot of tests

32:24

tend to feel pushed towards making smaller things.

32:27

So instead of one horse-size duck,

32:28

we have a hundred duck-size horses,

32:29

and if you've got a big order.js normally,

32:33

and you start writing a lot of tests,

32:34

it wouldn't be surprising at all to find

32:37

you have an order router controller,

32:38

and yada yada, lots of small tiny things.

32:41

But it's really easy, especially up on the stage,

32:44

to say this big, naughty mess of code is really bad,

32:47

and maybe it's even provably bad,

32:49

but it's also important to know that smaller isn't better

32:52

just by virtue of being smaller.

32:54

It has to be focused as well.

32:55

It has to be meaningful.

32:57

'Cause like, look at this case.

32:59

Where we got this whole stack

33:00

of all these different units.

33:02

If every single feature that we do

33:03

has the same six cookie cutter things

33:05

that we have to create, then all we're really doing

33:08

is creating that large object over

33:10

and over again with extra steps.

33:12

Now there's more files and direction,

33:14

but we're not actually designing code better.

33:17

So, you might ask, what's unsolicited

33:20

code design advice have to do with mocking?

33:22

Well, if we have a test of one of these layers,

33:25

and we mock out all the layers beneath it,

33:27

then what we can do using that tool

33:30

is create like a skyscraper, infinitely many layers,

33:32

never having to worry about the fact

33:34

that if something down at the bottom changes,

33:36

it'll break everything above us.

33:38

And so you tend to see teams who use a lot of mock objects

33:40

create really highly layered architectures.

33:43

And I get it, right.

33:45

Because layering feels a lot like abstraction.

33:49

You're doing a lot of the same motions.

33:50

You're creating a new file.

33:51

It's a small thing.

33:52

It's got a really clear purpose.

33:53

But it's not actually necessarily the same as

33:57

thoughtful design of the system.

34:00

Instead, I'd focus on generalizing the concerns

34:03

that are common across the features,

34:05

instead of just creating a checklist

34:07

of we do these six things for every story in our backlog.

34:10

So for instance, have a generic router,

34:12

and controller, and builder, that's very adept

34:15

and can handle all of the different

34:16

resources in your application.

34:17

And then, you know, when you need

34:20

some custom order behavior,

34:22

treat the controller like an escape patch,

34:24

like a main method.

34:25

So this is just plain old JavaScript

34:27

that's focused on nothing other than

34:28

whatever's special about orders,

34:30

as opposed to just building another stack

34:32

and increasingly broad application.

34:34

So yes, make small things,

34:36

but make sure that they're meaningfully small,

34:38

and not just arbitrarily small.

34:39

The last dubious thing that I see people do with mocks

34:42

is over-reliance on verification

34:45

or verifying that a particular call took place.

34:48

And I'm a firm believer that how we write assertions

34:53

in our tests, especially if we're practicing

34:55

some kind of test first methodology,

34:56

will slowly and subtly steer the design of our code.

35:00

So let's say you run a petting zoo,

35:02

and you were given a copy of testdouble.js for your birthday

35:06

(audience laughs) and you're really excited,

35:08

because you love petting zoo,

35:10

and you can finally verify every pet.

35:11

So, you know, somebody pets the sheep,

35:13

it was pet one time.

35:15

Somebody pets the llama, pet one time.

35:16

Sheep again, now we can verify two times.

35:19

Really exciting.

35:20

Sorry, nobody pets the crocodile.

35:21

Sorry, crocodile.

35:23

But you could write a test for it.

35:24

And there's a problem in your petting zoo,

35:26

which is that kids' hands are dirty,

35:28

and they make the animals dirty,

35:29

but the pet function doesn't say how dirty,

35:32

and so we just have to guess,

35:33

and we clean them daily with a 10 p.m. chron job

35:36

that hoses down all the llamas.

35:38

(audience laughs)

35:39

It's hugely inefficient and wastes water.

35:43

How did we get here?

35:44

Well, take a look at this test.

35:45

So we have a few stubbings where we ask

35:48

if the kid likes the sheep.

35:49

Yeah, they like the sheep.

35:50

We ask if they like the llama.

35:51

They do.

35:52

They don't like the crocodile.

35:54

Pass all that into the subject,

35:55

and then we verify the sheep was pet,

35:57

and the llama was pet, but the croc wasn't.

36:00

And that's a real tidy looking test.

36:01

And the subject almost writes itself as a result.

36:04

We have those two dependencies.

36:05

It takes in the kid and the animals for each of the animals.

36:08

If the kid likes the animal, we pet the animal, great.

36:11

Passing test.

36:12

But nobody, because the mock library

36:15

made it so easy to verify that call,

36:17

nobody thought to ask what should pet return.

36:21

If we didn't have a mocking library,

36:22

it would have to return something

36:23

for us to be able to assert it,

36:25

but we didn't have to, because we faked it out anyway.

36:27

And it's an important question to ask.

36:29

And I love this, because it gets

36:32

the fundamental point about tooling generally,

36:35

because tools exist to save time

36:37

by reducing the need for humans to think things,

36:40

and take action, in order to get a particular job done.

36:43

And that's fantastic, unless it turns out

36:45

that those thoughts were actually useful.

36:47

So I'm always on guard against any tool

36:50

that can reduce the necessary and useful thoughtfulness

36:54

as I'm doing my job, and that's one example of it.

36:57

So I've been critical of snapshot tests

36:59

because a lot of teams,

37:00

the median number of tests on a JavaScript project

37:04

has been and remains zero.

37:07

And so when you tell people like,

37:08

"Hey, here's the snapshot testing tool,

37:10

"and it'll test stuff automatically."

37:12

People were just, "Sweet, I'll check that box.

37:15

"And then that means I never have

37:16

"to worry about testing again."

37:17

And so, because that's a very obvious form of abuse,

37:21

I'm critical of snapshot testing tools.

37:23

That said, if you're a highly functional team

37:25

and you know this nuanced fuse case,

37:27

where you're only using it to make sure that

37:29

your dependencies don't break underneath you.

37:31

Great, but that's like one percent.

37:34

99 percent are just abusing them.

37:35

And I feel the same way really

37:38

about most uses of mock objects.

37:40

Being able to verify calls may end up discouraging

37:44

a lot of people from writing pure functions

37:45

when they otherwise would.

37:46

And pure functions are great

37:47

'cause they don't have side effects,

37:49

and things are more composable.

37:50

So we should be writing more of 'em.

37:51

So if you do use mock objects

37:54

when you're isolating your tests,

37:55

just be sure to ask, "What should values return?"

37:59

And I'll always default to assuming

38:00

that things should return values.

38:02

Because it just leads to better design.

38:03

And in this case, when we call pet,

38:05

and we pass in an animal,

38:07

what could it return but a dirtier animal,

38:09

and then we could use that information

38:10

to figure out when to wash our animals.

38:12

So taking this same example,

38:14

let's set these stubbings instead of the verifications.

38:17

So when we pet the sheep, we get a dirtier sheep,

38:19

and when we pet the llama, we get a dirtier llama.

38:21

And then we get a result back now from our subject,

38:24

so we can actually assert, and we end up

38:26

with a dirty sheep and a dirty llama and a clean crocodile.

38:29

So now the change here,

38:30

first we're gonna get rid of this forEach.

38:32

Anytime you see forEach anywhere in your code,

38:35

it means side effect, because it doesn't return anything.

38:38

So we're gonna change that to a map.

38:39

So we're trading one array for another.

38:42

And then in the code path where

38:43

the kid doesn't like the animal.

38:45

Excuse me, first in the code path

38:47

where the kid does like the animal,

38:48

we'll return whatever pet returns.

38:49

And else, we'll just return the animal as it was.

38:53

And now we got that test to pass.

38:55

So the benefit here is now we know

38:57

who to wash and when, saving on water.

38:59

And that's really great.

39:01

There's just one little problem remaining,

39:03

which is that when you run this test,

39:04

you're gonna get this big nasty paragraph

39:07

that I wrote three years ago,

39:08

that says, "Hey, yo, you just stubbed and verified

39:12

"the exact same method call.

39:13

"That's probably redundant."

39:15

And so that's a little bit quizzical.

39:17

So just to explain.

39:17

We've got all of these verify calls down at the bottom,

39:20

but they are almost provably unnecessary

39:22

'cause we're stubbing the same thing

39:24

and also asserting the return value.

39:27

The only way for them to get the dirty sheep

39:29

is to call that method exactly that way,

39:32

and a lot of people like a llama at a petting zoo,

39:35

just can't let of verifying

39:37

the hell out of every single call.

39:38

Trust me, you don't need to.

39:39

Just delete it.

39:40

In fact, I only generally verify calls

39:44

to the outside world at this point.

39:46

So if I'm writing to a log,

39:47

or if I'm scheduling something

39:48

in a job queue or something like that,

39:50

where it doesn't give me any kind of response,

39:53

or I don't care about the response.

39:54

Then like invocation verification might be worthwhile,

39:58

but usually if I'm designing my own private APIs,

40:00

I always want to be returning values.

40:01

The common thread between all three of these things

40:04

is that there's a habit, I think,

40:06

of neglecting tests' design feedback,

40:08

when we're using mocks.

40:10

And the whole purpose of mock objects,

40:12

the reason they were invented,

40:13

the reason these patterns exist,

40:14

is to write isolated unit tests to arrive at better designs.

40:18

It was not just to fake out the database.

40:21

So if that's why you use mocks,

40:22

spoiler alert, you've been doing it wrong.

40:28

I hate to say that, but like it's

40:30

really depressing ...

40:35

how they have been misused.

40:36

But I'm all done talking about that now.

40:38

Except to say that when a test inflicts pain,

40:43

people tend to blame the test,

40:45

'cause that's the thing that you're looking at.

40:46

It's the thing that you feel like it's causing pain.

40:48

But the root cause is almost always in the code's design,

40:51

and hard to test code is hard to use code.

40:53

So we're all done talking about these different abuses.

40:57

I want to move on to the one good use.

40:59

Finally the positive, the happy way

41:02

that I love using mocks.

41:03

The reason that I maintain a library about it.

41:05

And it all comes back to this thing I call

41:08

London-school test-driven development.

41:10

I use this phrase because it's based on the work

41:12

of Nat Price and Steve Freeman

41:14

in their really seminal book

41:16

"Growing Object-Oriented Software Guided by Tests."

41:19

It's called London 'cause they're members

41:21

of the London extreme programming group.

41:23

Some people call this outside in test-driven development.

41:26

Some people say test-driven design.

41:28

I call it discovery testing,

41:30

because I've changed a few things.

41:31

It's very important that I brand everything that I do.

41:35

And what it does is it solves --

41:38

It helps me deal with the fact

41:40

that I'm a highly anxious and panicky person.

41:43

I'm a really, really bad learner, for example.

41:48

I seem to take every single wrong path

41:50

before I end up at the right ones.

41:53

And I gave a whole talk just about this.

41:56

How we're all different people

41:57

and how developers can customize work flows

41:59

to suit their particular traits,

42:02

called "How to Program," last year.

42:04

And it's sort of the ideology

42:06

that undergirds this particular presentation.

42:09

Because earlier in my career, I was full of fear,

42:12

like blank page syndrome.

42:14

I was just afraid that staring at my IDE,

42:18

that I'd never figure out how

42:19

to make code happen inside of it.

42:21

And that fear led to really uncertain designs,

42:25

big, knotty complex stuff with tons of conditionals

42:28

and comments and stuff,

42:30

and as soon as I got anything working,

42:32

I would just publish it immediately

42:33

for fear that any future changes would break it.

42:35

And complete doubt that if anyone asked me,

42:37

"Hey, could you finish this in a week?"

42:39

I just had zero confidence that I'd be able to do it.

42:41

But where I am now is I have a certain ease about myself

42:45

when I approach development because I have processes

42:47

that give me incremental progress.

42:50

I'm gonna show you that in a second.

42:51

And confidence, because through that process,

42:54

I've realized that coding isn't nearly as hard

42:57

as I always thought it was.

42:58

And doubt, because I'm just really self-loathing individual.

43:02

But I like to think that I'm doubting

43:03

about more useful things now than I used to be.

43:06

So let's say, suppose that you write talks,

43:08

but it takes you way too long to make all these slides,

43:11

and so you decide we're gonna automate it.

43:12

We're gonna take something that takes our notes,

43:14

and runs it through sentiment analysis,

43:16

to pair it up with emoji,

43:17

and then create a keynote file.

43:20

So we start with the test,

43:22

and at the beginning of the test,

43:23

we don't know how we're gonna do this.

43:25

It seems almost impossibly ambitious.

43:27

So we just write the code that we wish we had.

43:30

I wish I had something that could load these notes.

43:32

I wish I had something that could pair

43:34

those notes up with emoji and give me slides back.

43:36

And then I wish I had something that could create

43:38

a file given those slide objects.

43:40

Then of course, I've got my subject.

43:42

And the test can just be a simple.

43:44

I probably only need one test case.

43:45

Creates keynotes from notes or something.

43:48

So I run my test.

43:49

It errors out, says load notes doesn't exist,

43:52

but it's just a file.

43:53

I can create a file.

43:54

I run my test.

43:54

And this other file doesn't exist.

43:56

So I touch it, run my test.

43:58

This third file doesn't exist.

43:59

Touch it, run my test.

44:02

And now my test passed.

44:03

Now, this is really, really, really tiny steps.

44:07

It's just plumbing,

44:07

but to me, it's the difference between

44:10

getting nothing done through analysis paralysis,

44:12

and just having incremental forward progress

44:14

throughout my day kind of being baked into my work flow.

44:16

Feels like paint-by-number.

44:18

And you can design work flows that

44:19

actually give you the messages to tell you what to do next

44:22

and prompt and guide your actions in a productive way.

44:26

So here, so far where we're at,

44:28

you know, we have this entry point.

44:30

And we think we maybe could break things down

44:32

into these three units.

44:34

But let's continue with writing the test itself.

44:36

So I'll start with some notes.

44:39

I know that I'm gonna need notes,

44:40

so I invent right here a note value object,

44:44

and then I say, "Okay, well."

44:45

And I call load notes, I'd probably need to pass

44:47

this string to search for topics.

44:49

I'll call back with these notes,

44:50

and then I need some slides,

44:53

so I invent a slide object.

44:55

And when I pass my notes to this pair emoji thing,

44:57

it should give me those slides back.

44:59

My subject then, I pass in that topic,

45:02

and probably a file path to save the document,

45:04

and so I'll verify finally that create file

45:07

was called with slides and a file path.

45:09

Run my test, and now, of course,

45:12

you get a different failure.

45:14

It says load notes is not a function.

45:16

This is an artifact of the fact

45:17

that the default export in node.js

45:19

is just a plain object.

45:21

So I can go in and just export a function, instead,

45:23

and I can see the other two coming.

45:25

And so I'll go ahead and export functions

45:27

from those files as well.

45:28

Run my test again,

45:30

and now what it says is it expected

45:32

to be called with an array of this slide

45:34

and with this file path, but it wasn't called.

45:38

And so finally, finally after all this work,

45:40

we get to write some real code.

45:42

And it turns out though, that writing this code is

45:44

an exercise in just like obviousness,

45:48

because we've already thought through

45:49

literally everything it does.

45:50

We know that we have these three dependencies.

45:52

We know that our exported API is

45:55

gonna have these two arguments.

45:56

We know that load notes takes topic

45:58

and then calls back with notes.

46:00

We know we pass those notes to pair emoji,

46:02

which gives us slides.

46:03

We know that the create file method

46:04

takes slides and a path, and then we're done.

46:07

So we run our test, test passes, and that's it.

46:10

And so you might be looking at it

46:12

and be like that was a lot of talking

46:14

to write a five line module,

46:15

and you'd be right.

46:17

It was a lot of talking, but those five lines --

46:21

I think they belie the amount

46:23

of stuff that we just accomplished.

46:25

Right?

46:25

We decided pretty clearly through usage

46:28

what our customers need to provide us

46:30

to implement this thing.

46:32

We figured out that if we pass a topic into this thing,

46:35

we can get some sort of value type back.

46:37

We also identified a data transformation

46:39

converting those notes to slides.

46:41

And finally, we are confident that if we pass slides

46:43

and the file path to something,

46:45

we'd be further along in the story

46:46

of automating this work flow.

46:48

Job number one, the subject is done.

46:52

That top layer, even though it's really short,

46:54

very rarely will I ever have to go back and change it again,

46:57

unless the requirement significantly changed.

47:00

Number two, the work has now been broken down.

47:03

So instead of having in my working memory

47:05

the entire complexity of my overall system,

47:07

I have this outside in approach

47:09

where it's like I've got these three jobs remaining,

47:11

and I can do them in any order,

47:12

and they don't have to know about each other,

47:13

and it's much easier to understand and think about.

47:16

And third, all these contracts are clearly defined.

47:19

I know what goes in and out of each of these things,

47:22

so I have no risk of squirreling away

47:23

and building a bunch of objects

47:24

with complexity that ends up not being necessary

47:27

or maybe an API that doesn't fit quite right

47:30

with the thing that ultimately needs it.

47:32

So playing things ahead a little bit,

47:35

I got these values on note and slide,

47:38

and those exist off to the side

47:40

because they're just passed in

47:41

as arguments back and forth through the system,

47:43

but if I play forward how the rest of this tree would flow,

47:47

I imagine that to load my notes

47:49

I'd probably need to read a file,

47:50

parse that outline to some sort of logical set,

47:54

and then flatten all the points out

47:55

so that the story is sequential just like a slide deck.

47:58

This first thing is I/0, so I'd wrap it

48:01

with a wrapper like we talked about earlier.

48:02

The other two are pure functions,

48:05

which means I can test them,

48:06

delightfully, with no mocks needed.

48:08

The pair emoji job would probably need

48:11

to tokenize those notes,

48:12

pass them to something that does sentiment analysis,

48:14

and then convert those to slide objects.

48:16

The first thing would be a pure function.

48:18

The second thing would probably wrap

48:20

any of a dozen npm modules that do sentiment analysis.

48:24

The third thing would be another pure function.

48:26

Real easy.

48:27

The third job, creating that file.

48:30

We'd probably want to take those slide objects

48:32

and like indicate layout and text up here, emoji down here.

48:35

Probably want to generate AppleScript commands

48:37

in some sort of structured way

48:39

so we can rifle through a set of them

48:41

to create the presentation.

48:44

And then finally something to automate Keynote.

48:45

The first thing, again, is a pure function.

48:48

So is the second item.

48:49

And then the third one, we'd probably just like --

48:51

we'd shell out to osascript binary,

48:54

and just wrap that and pass all those commands on through.

48:58

What this approach has given me as I've developed it,

49:01

and mapped my personal work flow to this one,

49:05

over the years, is reliable incremental progress

49:08

at work every day, which is something

49:10

that I didn't have earlier in my career.

49:12

Also, all of the things that I write

49:14

have a single responsibility,

49:16

just sort of shakes out that way.

49:17

They're all small and focused.

49:18

And they all have intention revealing names

49:20

because all of the things that I write

49:22

start out as just a name and a test,

49:24

so they'd better say what they do clearly.

49:26

It also leads to discoverable organization.

49:29

So a lot of people are afraid of like

49:31

oh man, too many small things in one big file,

49:33

I'll never find anything.

49:35

But because I visualize everything as an outside in tree,

49:38

I sort of just tuck every subsequent layer

49:40

of complexity behind another recursive directory.

49:42

So if you were interested in how this thing works,

49:45

and maybe only at a cursory level

49:46

you look at that first file,

49:48

but if you want to dig in,

49:48

you know that you can dive

49:50

into the directories underneath it.

49:51

Separates out values and logic,

49:54

and what I found is that by keeping

49:58

my data values off to the side,

50:00

and my logic completely stateless,

50:02

things tend to be more maintainable.

50:04

And what I end up with at the end of the day

50:06

is a maximum number of simple, synchronous pure functions

50:10

that are just logic, that don't need to know anything

50:11

about promises or call backs or anything like that.

50:13

And so this has made me really, really happy.

50:16

Okay, so that's all I got.

50:17

You may mock me now.

50:19

I know that you guys have been super patient.

50:21

This was a long talk.

50:22

There was a lot of slides.

50:23

Again, I come from a company, Test Double.

50:27

We, if your team is looking for senior developers

50:29

and you care a lot about improving,

50:31

and this is like one of the ways

50:32

you might be interested in improving,

50:34

myself and Michael Schoonmaker are here today.

50:36

Wave, Michael.

50:38

Yeah, he's up in the front row.

50:39

We'd love to meet ya tonight, and hang out.

50:43

You can read more about us here or contact us.

50:46

We're also always looking for new double agents.

50:48

If you're interested and passionate about this stuff,

50:50

and you want to do consulting,

50:51

check out our join page and learn

50:53

what it's like to work with us.

50:55

Quick shout out to an even less popular library

50:58

that we wrote called teenytest.

51:00

All of the code examples and the test examples in this

51:02

are real working tests.

51:03

This is our zero API test runner

51:06

which we really love using for small projects and examples.

51:08

The only other time I've been in San Antonio,

51:11

I gave another talk about testing.

51:12

I apparently have like a niche.

51:13

(audience laughs)

51:15

It's entitled how to stop hating your tests,

51:17

and if you liked this talk,

51:19

I think that would be a really good companion.

51:21

'Cause it's about more than just mocking.

51:24

So finally, would love all your feedback,

51:27

would love your tweets, and whatnot.

51:29

I'm just excited to meet as many of you as I can today.

51:31

Got a lot of stickers and business cards for you,

51:34

so that's it. I'm all done.

51:36

Thanks a lot for your time.