Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Testing Without Mocks

jamesshore.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Testing Without Mocks

#21

Post by kaczordon »

jrockway wrote: post #18
kshay wrote: 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 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 replaci…

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.

Re: Testing Without Mocks

#22

Post by bbq »

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 to write nullables, and call them mocks, fine. Not important.

Re: Testing Without Mocks

#23

Post by e___ric »

valenterry wrote: post #8
revskill wrote: 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 ?

What's your definition of "pure function". Apparently not "pure function" in the sense of "pure functional programming", because if that were so, your claim would just be wrong. Counterexample: "printToConsole: IO[null]": is a pure function but still not easy to test.

The definition of "pure function" I'm familiar with from functional programming has no side effects including I/O. Assuming 'printToConsole' is performing I/O, you're describing a impure function.

Re: Testing Without Mocks

#24

Post by BiteCode_dev »

jmholla wrote: post #17
kaczordon wrote: post #7

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

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.

Re: Testing Without Mocks

#25

Post by stuaxo »

Obviously he's keeping the interesting bit about how this works for the actual course, but I already only mock bits right on the edge, e.g. the point where the system would connect to the outside world, and that seems to work.

What I'd really like, is some way of acknowledging redundancy - lots of tests ultimately go through the same code underneath, it would be good if that could be tested only once, and then the data replayed from those points but done in such a way that everything is still nice and readable.

Re: Testing Without Mocks

#26

Post by willio58 »

bbq wrote: 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…

Agreed and I find this happening a lot in discussion of testing. It seems everyone/every company has "their way" of doing testing, which at times even includes new words for certain concepts that they find useful (e.g. stubs) and then the conversation about testing gets muddled by people doing things/naming things differently.

I only recently got into testing my code and while I love writing tests, getting started was kind of difficult because there was just so much noise. I eventually had to find one person to follow in my space (Kent C. Dodds) and just kind of go all in on his methodology.

Re: Testing Without Mocks

#27

Post by GrumpyNl »

willio58 wrote: post #26
bbq wrote: 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…

Agreed and I find this happening a lot in discussion of testing. It seems everyone/every company has "their way" of doing testing, which at times even includes new words for certain concepts that they find useful (e.g. stubs) and then the conversation about testing gets muddled by people doing things/naming things differently. I only recently got into testing my code and while I love writing tests, getting started wa…

I don't always test my code But when I do, I do it in production.

Re: Testing Without Mocks

#28

Post by Aeolun »

kaczordon wrote: post #7
kshay wrote: 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.

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.

Re: Testing Without Mocks

#29

Post by dkarl »

jrockway wrote: post #18
kshay wrote: 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 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 replaci…

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

Re: Testing Without Mocks

#30

Post by Izkata »

jmholla wrote: post #17
kaczordon wrote: post #7

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

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.

"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.
Post reply on HN