Hacker News Reader

Comment by kshay | Hacker News Reader

> The factory should create a “Nulled” instance that disables all external communication, but behaves normally in every other respect....

>...For example, calling LoginClient.createNull().getUserInfo(...) should return a default response without actually talking to the third-party login service.

So... a mock.

View on HN

No that’s not a mock that’s a stub. See this book from software engineers at Google, it talks about various test doubles: https://abseil.io/resources/swe-book/html/ch13.html

They use the word mock several times to explain stubbing. I think they mean stubbing is a type of mocking not an independent approach. They even use a mocking library to create stubs in the Google article.

Indeed, like people stating something is a deferred or a future instead of promise, and then pointing out a minor difference in their approach that justifies a whole new taxonomy.

"Mock" can be both a noun and a verb. As a noun, it's an alternative to stubs, fakes, and other such things. As a verb, it refers to the "monkey patching" method of putting those into place, in a way that undoing it is automatic and won't leak into other tests. The title seems to be referring to this second version, showing us ways to avoid patching with things like dependency injection.

Also https://www.martinfowler.com/articles/mocksArentStubs.html

Mocks are for objects, stubs are for responses and ‘fakes’ are basically the same thing as mocks.

Fakes are not mocks. A fake is an actual (simplified) implementation of the dependency.

For example, if your dependency is a distributed key-value store, a fake would expose the same API but using an in-memory hashmap under the hood.

Yeah no, that’s a mock. At least, that’s been a mock ever since I started prgramming 15 years ago. Only later did libraries that automatically mock dependencies appear (and I presume people suddenly felt a need for a new name for not-automatically mocked dependencies?

Exactly. All those talks are always going to tell you the same things:

- limit side effects to your program boundaries

- abstract boundaries with utility functions

- mock program boundaries for integration tests in those utility functions

And then they pretend they didn't see the mock part.

I think we call those "fakes", and reserve mocks for those tests that count the number of times a function was called, yielding "change detector tests".

Personally, I find it best to not be too concerned about the terminology, and make sure your test doubles get the data that the code under test needs to the place that needs it. The more real code you can involve in integration tests, the better; only look at replacing real code with test doubles if there is a performance or reliability downside. Databases have never hit that performance/reliability downside for me; network services do.

No, fakes are specifically designed to emulate the underlying dependency somehow so that you can assert on it’s state later. Stubs don’t try to do that at all and are mostly for returning a default response.

> Personally, I find it best to not be too concerned about the terminology

I second this. My experience is that some people know this terminology if they're actively learning or teaching the techniques, but most of the people I've worked with who know the techniques and apply them successfully don't know the terminology and use the word "mock" universally, so it usually creates more confusion than clarity to try to distinguish the different kinds of test doubles by name.

The nulled instance continues to be available in production, which has different pros and cons than a conventional mock class which is only available when running tests. Seems worth a different name so we can compare and contrast the two.

I’m not sure I manage to follow the author correctly, but to me it seems that by “mock” they strictly refer to external mocking libraries, in the sense of JS’s `testdouble` [1] or Java’s `Mockito` [2]. The static fake object as returned by `LoginClient.createNull().getUserInfo(...)` appears to be a “Nullable” for them.

[1] https://www.npmjs.com/package/testdouble

[2] https://site.mockito.org/

> Folks in the know use mocks and spies (I say “mocks” for short in this article)

I think the issue is "a mock" is a generalized term that implies different things depending on the usage. More junior developers think that it only means when you have an external entity that you have control over that "mocks" the external service that you don't (shameless plug, I built https://mockadillo.com for this). But yeah, these are obviously mocks and the article kind of doesn't make sense.

Reply on news.ycombinator.com