Comment by CuriouslyC
12 days ago
I've worked with a lot of pro-mocking engineers, and the time they spent on mocks easily outstripped the time a good build engineer would have spent creating a fast reusable test framework using real databases/dummy services/etc. The mocks won not because they were better or more efficient, but because of lack of deeper engineering skill and cargo culting.
> the time they spent on mocks easily outstripped the time a good build engineer would have spent creating a fast reusable test framework
This goes back to team size and skills. Not all teams have build engineers. And not all mocks are so complicated that they take up that much time.
Again, it depends on the scope and the resources. The article goes too far by calling mocking an anti-pattern. It simply isn't.
If I didn't have the team to properly do a good test build I would tell all my engineers to design their code to not need mocks if at all possible and call it a day at 85% coverage. That's very doable with dependency injection and modular function libraries. The time spent not chasing full coverage could be better spent improving CI/integration testing/deployment.
It depends. The type of project affects the decision too.
If it's a small, standalone CRUD app on a SQLite database, mocks would probably be a bad option, sure.
On the other hand, it could be an integration platform that integrates with many third-party services. Some of them may not have test environments. Or some of the integrations may be written by third-party contractors, and we can't expose service credentials because of poor permissions granularity. Mocks are a good option there.
That engineer may have spent a couple of dozen hours on their mock. But the engineers who spent time on a test framework that uses real databases will soak up thousands of developer hours in CI time over the next decade.
Spinning up DB instances is a lot faster now than it used to be in the past. There are even modules for in-memory instances of certain databases. The speed of a unit test vs. that of one that uses an actual database is small enough for it to be a real consideration.
That being said, of course, "it depends" on your use case. But I've found setting up this sort of test environment quite a bit easier now than writing database mocks, a lot less time-and-maintenance intensive, and relatively quick to run in any environment.
(Also, in a decade, I'm pretty confident this gap will get even smaller, while the time to maintain mocks will stay constant)
Each mock needs to be maintained, sanity checking against the latest behavior of the actual dependency. And CI costs hardware, not developer time if he has anything else to work on.