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

Why a mock doesn’t work

nedbatchelder.com

Post reply on HN
Print view View original

41–50 of 77 posts

Re: Why a mock doesn’t work

#41

Post by jayd16 »

pojzon wrote: post #32

I really don't like that the topic title is a general statement but the article under is talking strictly in python landscape as an example and not discussing the idea itself. Mocking by itself works fine. It's a good idea that works if used correctly. Misusing it or bad usage leads to issues - duh. I'm familiar with the narrative that anything that is too hard (to get right at the first try) in our field means that…

But I want to hire mediocre developers and get expert results. Sometimes that's fantasy but that's why people want error resistant patterns.

Re: Why a mock doesn’t work

#42

Post by aasasd »

hinkley wrote: post #16
stephen wrote: post #13

Agreed with the articles, mocks are very tied to implementation details. I almost always prefer state-based testing: https://martinfowler.com/articles/mocksArentStubs.html As "observable state goes from a to b" is much closer to a business/functional requirement that will still/always be true, regardless of refactorings. Refactoring in codebases with state-based tests is a pleasure; in codebases with mock-based tests…

Dependency injection leads to elaborate, brittle fixtures that become more elaborate and arcane over time. And the sunk cost fallacy has people working for hours (and I’ve witnessed pairs spend two days, that’s over three man days!) trying to maintain them. I use mocks to arrange state A without going through all the business rules involved in creating state A. But you have to expose the states to do it, which can ma…

I don't see how you decided that DI requires some kind of special fixtures that are more complex than mocks.

Mocks are generalized fixtures—just a reusable way to create them. And you can use them with DI. Only the method of delivery is changed, from an implicit backdoor to an explicit argument.

DI puts new requirements on production code and tests that aren't related to a specific mock, that much is true. At least if there's no automatic way to create ‘default’ dependencies.

Re: Why a mock doesn’t work

#43

Post by aasasd »

stephen wrote: post #13

Agreed with the articles, mocks are very tied to implementation details. I almost always prefer state-based testing: https://martinfowler.com/articles/mocksArentStubs.html As "observable state goes from a to b" is much closer to a business/functional requirement that will still/always be true, regardless of refactorings. Refactoring in codebases with state-based tests is a pleasure; in codebases with mock-based tests…

> As "observable state goes from a to b"

You might also notice that this is equivalent to a function that accepts a and returns b. Which lets one use equivalence partitioning to plan the tests: https://en.wikipedia.org/wiki/Equivalence_partitioning

Except that with singletons, ‘context objects’ or similar quasi-global state, the effect might be non-isolated, and effects may be silently introduced that the calling code doesn't know about.

Re: Why a mock doesn’t work

#44

Post by nedbat »

adrianmonk wrote: post #36
zzzeek wrote: post #3

Earlier quoted context omitted.

no, this blog post is absolutely on point and correct. it can be extremely inconvenient and complicated to get around using mocks in many situations where you want to test things, so we want to use mocks when appropriate. Then, you definitely want to mock at the most specific level possible. while mocking in a way that is specific to how modules are imported is technically "fragile", in that it is deeply dependent on…

I think they are asking a question about Python, not about mocks. I was also very surprised Python does it this way. Normally I would expect "import" statements in a language to just rearrange the namespace and have no other effects at all. The author explains that it doesn't work that way: > “from mod import val” means, import mod, and then do the assignment “val = mod.val”. In other words, I would expect an import…

How is "altering a symbol table" different than "creating a new variable"? Imports have to create a new variable of some sort: their entire point is to provide a name that you can use.

"import mod" defines mod, which didn't exist in your module before.

"from mod import val" defines val, which didn't exist in your module before.

Re: Why a mock doesn’t work

#45

Post by aasasd »

nedbat wrote: post #34
pojzon wrote: post #32

I really don't like that the topic title is a general statement but the article under is talking strictly in python landscape as an example and not discussing the idea itself. Mocking by itself works fine. It's a good idea that works if used correctly. Misusing it or bad usage leads to issues - duh. I'm familiar with the narrative that anything that is too hard (to get right at the first try) in our field means that…

What title would you prefer? "Your Python mock might not work, but it could still be a good idea if you do it right, and here I will explain how"? :) I didn't mean to imply that mocking is bad. Is that what you took from it? Why would I explain how to get mocks to work if I thought people shouldn't use mocks?

Personally I've actually come to prefer such titles—where the thesis is in the title, and I can judge at once whether I should read for details. I'd aim for about 200 characters. HN is already full of uninformative links.

Since we're in this discussion, it'd be fun to change the title to “Why Python tests may fail to mock imported module functions, and a better approach to doing that”.

Re: Why a mock doesn’t work

#46

Post by moron4hire »

stephen wrote: post #13

Agreed with the articles, mocks are very tied to implementation details. I almost always prefer state-based testing: https://martinfowler.com/articles/mocksArentStubs.html As "observable state goes from a to b" is much closer to a business/functional requirement that will still/always be true, regardless of refactorings. Refactoring in codebases with state-based tests is a pleasure; in codebases with mock-based tests…

A situation in which I've used mocking well: testing parsing of data coming over a serial port. I have had several situations to need to parse common data formats coming from hardware over a wire and mocking that data with recorded streams is super helpful for making sure your parser is working right.

Re: Why a mock doesn’t work

#47

Post by nedbat »

nedbat wrote: post #38
pojzon wrote: post #35

Earlier quoted context omitted.

A better question would be: "Why would I use a generic title, if I dont agree with it in my own article?" And the answer would be: " A click-bite title"..

I'm not sure what your objection is. People try to use mocks, and they don't work because they've mocked the wrong name. I explain this in the article. The article is about why their mock didn't work. How is this a misleading title? How is this a title I don't agree with? Are we talking about the same piece and the same title? You seem to be under the impression that I am trying to tell people not to use mocks. Have…

I notice that the title on HN is "Why a mock doesn't work," which could be interpreted as "Mocks don't work." My title was (and still is) "Why your mock doesn't work." I don't know if that is the source of the confusion.

Re: Why a mock doesn’t work

#48

Post by jchook »

“...there are other approaches to solving the problems of isolating your product code from problematic dependencies.”

What are some other approaches?

I have followed the redux-saga pattern with success but how else should we accomplish the same goal?

Re: Why a mock doesn’t work

#49

Post by j88439h84 »

jchook wrote: post #48

“...there are other approaches to solving the problems of isolating your product code from problematic dependencies.” What are some other approaches? I have followed the redux-saga pattern with success but how else should we accomplish the same goal?

See the links at the top of the post. Both are excellent.

Re: Why a mock doesn’t work

#50

Post by j88439h84 »

frenchman99 wrote: post #28
mpweiher wrote: post #17

Why I don't mock: https://blog.metaobject.com/2014/05/why-i-don-mock.html

You're talking about mocking database calls though. In my line of work (insurance brokerage), we use lots of insurance APIs and they are sometimes very slow (+20 seconds / call) or completely down at random hours. There is simply no way around mocking those API calls if you want a fast and reliable testsuite.

Take a look at the links at the top of the post. They discuss a great alternative to mocking slow services: fakes.
Post reply on HN