3 ms·
> Mocks should be the last thing you add to any test suite and they should only be used to mock out external services or slow systems. It really depends what y
by benjiweber 15y ago
> Mocks should be the last thing you add to any test suite and they should only be used to mock out external services or slow systems.
It really depends what you're trying to achieve from your tests. I find a combination of all of:
1. Mockist tests that mock /all/ dependencies
2. Tests that stub out interactions with other layers (e.g. test the entire model)
3. Full integration tests that test the whole system with real dependencies (real db, real services)
works quite well.
The first set help you design and document your implementation through mock specifications.
The second allows you to assert the intended behaviour of the code without tight coupling to the implementation. You're less likely to break these when refactoring.
The third is the most likely to find real bugs in my experience. They're also generally more difficult to write and take longer to run, but valuable.
Mock-everything tests aren't good at finding defects but they're not without value.
- prateekdayal 15y agoI have seen that over time, when you refactor code and tests that use mocks, its a good idea to take out the mocks and replace them with actual objects. Mocks are important early on because you are just discovering the interfaces but over time, they can be replaced by real objects (this obviously can't be done for third party interactions). In the end, there is no substitute for integration tests. We make it a point to write integration tests for atleast all happy paths.