Golang

2201 readers

7 users here now

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.

founded 1 year ago

MODERATORS

[email protected]

Don't use mocks (joeblu.com)

submitted 1 year ago by [email protected] to c/[email protected]

3 comments fedilink hide all child comments

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.

top 3 comments

sorted by: hot top controversial new old

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Mocking and dependency injection don't seem to be mutually exclusive, if anything dependency injection can make it easier to get the component you're testing to interface with the mock

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

How would you isolate your thing for testing then without mocks? Contract Driven Development is the best thing to decouple development teams from eachother so that they can continue to work on their part as the teams have agreed on the API.

And I doubt it's different in Go.

[–] [email protected] 1 points 1 year ago

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…