The software we develop runs as the sum of its parts, not as ‘isolated units’ sooooo… try to limit the amount of mocking you do!!!
When we test our software with its dependencies stubbed out, yes the tests are quicker BUT ultimately what are we testing? …. a version of our software that never gets to prod 👎🏻👎🏻👎🏻.
Mocking can be useful but I definitely don’t reach for it as a default approach. It often requires significant architectural changes to our apps to support it such as the use of interfaces, virtual methods, repository patterns etc. Generally speaking I’ll only mock if its impractical (too slow) or impossible (no test version) to use real components.
If my production app is using SQL Server and a message queue I’m going to do everything in my power to get prod like test versions of these to run my automated tests against. It’s a myth that integration tests have to be slow. The Entity Framework team for example run 30K tests against SQL Server in a couple of minutes…
In practice limiting the amount of mocking for me often means using real test versions of things inside the org and probably having a real and a mock version of things which are outside the network such as a third party REST API as to not mock/stub these might be too slow. As part of my local loop development I’d execute unit tests against a mocked or stubbed out ‘REST API’ and then as part of the CI or overnight build I’d have integration tests running against the real REST API.
What is everyone doing? There is no right or wrong here, different things work for different developers/teams but personally I think mocking is overused.
