5 ms·

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

by kshay 4y ago

> 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.

BiteCode_dev 4y ago
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.
kaczordon 4y ago
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 https://abseil.io/resources/swe-book/html/ch13.html
- jmholla 4y ago
  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.
  - BiteCode_dev 4y ago
    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.
  - Izkata 4y ago
    "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.
- inadequatespace 4y ago
  Also https://www.martinfowler.com/articles/mocksArentStubs.html https://www.martinfowler.com/articles/mocksArentStubs.html
- Aeolun 4y ago
  Mocks are for objects, stubs are for responses and ‘fakes’ are basically the same thing as mocks.
  - Cyph0n 4y ago
    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.
    - Aeolun 4y ago
      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?
lnenad 4y ago
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 https://mockadillo.com for this). But yeah, these are obviously mocks and the article kind of doesn't make sense.
jotaen 4y ago
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 https://www.npmjs.com/package/testdouble [2] https://site.mockito.org/ https://site.mockito.org/
- drewcoo 4y ago
  > Folks in the know use mocks and spies (I say “mocks” for short in this article)
jrockway 4y ago
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.
- kaczordon 4y ago
  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.
- dkarl 4y ago
  > 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.
akkartik 4y ago
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.

by kshay 4y ago

BiteCode_dev 4y ago

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.

kaczordon 4y ago

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 https://abseil.io/resources/swe-book/html/ch13.html

jmholla 4y ago
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.
- BiteCode_dev 4y ago
  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.
- Izkata 4y ago
  "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.
inadequatespace 4y ago
Also https://www.martinfowler.com/articles/mocksArentStubs.html https://www.martinfowler.com/articles/mocksArentStubs.html
Aeolun 4y ago
Mocks are for objects, stubs are for responses and ‘fakes’ are basically the same thing as mocks.
- Cyph0n 4y ago
  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.
  - Aeolun 4y ago
    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?

lnenad 4y ago

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 https://mockadillo.com for this). But yeah, these are obviously mocks and the article kind of doesn't make sense.

jotaen 4y ago

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 https://www.npmjs.com/package/testdouble [2] https://site.mockito.org/ https://site.mockito.org/

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

jrockway 4y ago

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.

kaczordon 4y ago
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.
dkarl 4y ago
> 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.

akkartik 4y ago

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.