Hacker News Reader

Hacker News

Comment by smitty1e | Hacker News Reader

Parent Full thread

smitty1e

I don't grasp the difference between a mock and a fake.

Both are substitutes for an expensive or unavailable component.

Maybe the fake is more dynamic than the mock?

The point seems moot.

View on HN

Maybe more eloquently put:

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

Mocks, fakes, stubs. Every time I read this article I end up more confused than I was before.

I like Uncle Bob’s explanation:

https://blog.cleancoder.com/uncle-bob/2014/05/14/TheLittleMo...

That is a solid way to introduce the different test doubles. Thanks for the link. I agree, stubs and spies are my daily bread. I also use fakes very regularly. I hardly ever use mocks, for the same reasons in the post.

A fake is a 'local' or lower fidelity implementation of the real thing. A array/memory backed DB instead of postgres, etc.

A mock is a cache for a desired return value (which is hopefully what the real interface would correctly return).

Edit: actually sethammons link is great

I actually agree. I think the point the author is trying to make it that fake can be reused in more places and stay relatively same as the code updates.

But I personally think that instead of spending the time to write a fake, its better to just spend the time writing actual integration test with the real dependency (eg: just run the db in docker or something)

or if you don't want to spend that time, then just record the interaction (eg: db calls) and create "throwaway stubs". Use this stubs as long as they are relevant, and then generate new ones as your code grows. Save time "writing" any mocks, and you don't tend to couple too much with your mocks :P

> just run the db in docker

That creates unit tests that take ages to run - and fail surprisingly in hard to debug ways.

If running a micro service use sqlalchemy and switch your db to sqlite for testing purposes.

There are scalability limits to this but for most cases it works extremely well and is fast.

What he calls a fake is what I call a mock - although I don't think he's necessarily building a strawman here, there are developers who use mocks the way he's telling you not to, and they are creating the problems that he outlines. I'd change it from "don't use mocks" to "don't be stupid with mocks".

Mock has expectations about how the function is called. If you read a file from a disk, and you expect it only to be done once, a mock is "usable" in this scenario to count the number of invocations. Note that there aren't outside, observable, state changes or behavior involved in this. It is about the non-functional introspection.

Fake is just a simple implementation, like in-memory db to stand-in for a real one. In the optimal case, provided by library authors.

How I understand it:

A mock is a set of fixed data; sometimes people even load these from YAML documents and the like. They're often re-used for different tests.

A fake is a "fake" object created when needed, with the parameters you need.

Mock:

  user = load_user_mock()
  article = load_article_mock()
  run_test(user, article)

Fake:

  user = newUser(Name: "foo", Email: "foo@example.com")  # Or generate random data
  article = newArticle(User: user, Title: "bar")
  run_test(user, article)

The difference is somewhat subtle, but I often find mocks very inconvenient because you can't "just" change one without lots of stuff falling over. It's also much harder to do something "special" with them for that one test.

As a Python main I'm wondering if the difference has to do with a strictly typed language like the author's two examples, Go and Java, requiring more boilerplate and interface classes and so on, that in turn require more customization of the mock (since he writes that it "implements the API of what it replaces" which seems like it would be a strange thing to say about a python mock).

Reply on news.ycombinator.com