Writing good unit tests is made much easier by **dependency injection**. This lets you separate your code's behavior from that of your dependencies. Many people use **mocks** to add dependencies to unit tests. I think this is usually a mistake.

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.

  • BiggestBulb@lemmy.fmhy.mlEnglish
    1·
    1 year ago

    I’m assuming we’re talking about test mocks.

    I’m quite partial to using mocks within hard-to-reach code. I was curious the other day when I saw the Primeagen saying test mocks are awful - I’m not that heated about it either way and I think if it will take an hour of dev time or a simple mock I would always prioritize using the mock.

  • macniel@feddit.deEnglish
    1·
    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.

  • technologenesis@programming.devEnglish
    1·
    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

  • Ukcoder@programming.devEnglish
    1·
    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…