Live data from Hacker News

Testing Without Mocks

jamesshore.com

31–40 of 51 posts

Re: Testing Without Mocks

#31
post #28

Earlier quoted context omitted.

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

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.

Re: Testing Without Mocks

#32
My introduction to mocking was through C++ and googlemock, where you have to dependency inject the mock object to do any mocking. This always made sense to me, and could often make APIs nicer and more generic with this approach. The API for dependency injection just ends up an other public interface that you need to test, and one natural way to test it is with mock objects.

Then I learned about pytest, magicmock, and that the norm for other testing frameworks in other (mostly dynamic) languages is that you can replace whatever member or free function with a mock without this being part of the public interface of the original class or function. This feels insane to me, as this just tests implementation details.

Is there terminology to distinguish between these two kinds of mocking?

Re: Testing Without Mocks

#33
post #32

My introduction to mocking was through C++ and googlemock, where you have to dependency inject the mock object to do any mocking. This always made sense to me, and could often make APIs nicer and more generic with this approach. The API for dependency injection just ends up an other public interface that you need to test, and one natural way to test it is with mock objects. Then I learned about pytest, magicmock, and…

Poorly vs well structured code.

Re: Testing Without Mocks

#34
post #22

Lots of people in the comments here stuck on the boring semantic definition debate of mocks vs stubs vs nulls vs whatever. This is not really by what the article is about IMHO. It’s a great overview of how to grow and organize your application with some opinionated patterns that give some favorable properties to your system. The nullable stuff just helps achieve those properties. If you want to use a mocking library…

I think this might be a problem of expectation management that could stem from the title. A headline along the lines of “Patterns to organize your code for testability” might reflect the general character of the article more clearly. But as it specifically says “testing without mocks”, I was intuitively expecting something different, and even was a bit confused when the author suggested techniques that I would refer to as “mocking”.

Re: Testing Without Mocks

#35
post #4

If you make all your code as pure function, then testing is easy. First thing to do: Stop using class. Ask yourself first: Should i use a class here and there ? Wait, i miss something here: Writing pure functions is hard ?

Writing pure functions isn't necessarily hard.

However, solving a business problem with only pure functions is indeed hard

Re: Testing Without Mocks

#36
post #15
post #2

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

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)

Re: Testing Without Mocks

#38
post #34
post #22

Lots of people in the comments here stuck on the boring semantic definition debate of mocks vs stubs vs nulls vs whatever. This is not really by what the article is about IMHO. It’s a great overview of how to grow and organize your application with some opinionated patterns that give some favorable properties to your system. The nullable stuff just helps achieve those properties. If you want to use a mocking library…

I think this might be a problem of expectation management that could stem from the title. A headline along the lines of “Patterns to organize your code for testability” might reflect the general character of the article more clearly. But as it specifically says “testing without mocks”, I was intuitively expecting something different, and even was a bit confused when the author suggested techniques that I would refer…

Yes, exactly. “Bake your mocks into your third-party library implementations” is an interesting idea and might be a useful thing to do, but it’s certainly not “testing without mocks.”

Re: Testing Without Mocks

#39
post #2

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

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.

Re: Testing Without Mocks

#40
Hi everyone, author here. This article tends to raise a lot of questions. I'm happy to answer them.

(The most common question: isn't it the same as a mock? The answer is no, mocks are used for isolated, interaction-based testing, and this is for sociable, state-based testing. These are polar opposite approaches to testing with distinct tradeoffs. If you're not familiar with those terms, they're defined in the article in the "Foundational Patterns" section.)

Post reply on HN