Always interesting to hear different points of view on this subject. Personally I think mocks make sense to capture complex sets of interactions or otherwise difficult to reach error conditions, so I don’t think it’s a do or do-not kind of thing.

You are viewing a single thread.
View all comments
1 point

Unless I’m missing something, the author seems to think that a “Mock” means verification of exact /fixed/fragile call sequences, but instead advocates use of (undefined) “Fake” objects or alternatively skipping those unit tests and relying on integration or other high level tests for those parts of the system…

I can’t decide if they actually believe that “Fake” != “Mock” or it’s just to drum up traffic…

permalink
report
reply

Golang

!golang@programming.dev

Create post

This is a community dedicated to the go programming language.

Useful Links:

Rules:

  • Posts must be relevant to Go
  • No NSFW content
  • No hate speech, bigotry, etc
  • Try to keep discussions on topic
  • No spam of tools/companies/advertisements
  • It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Community stats

  • 20

    Monthly active users

  • 150

    Posts

  • 243

    Comments