Comment by brushfoot
3 months ago
Bad article.
Some of the advice is good, like decoupling I/O and logic where that makes sense. But the general idea of mocking being an anti-pattern is overreach.
This kind of thinking is overly rigid/idealistic:
> And with Postgres you can easily copy a test database with a random name from a template for each test. So there is your easy setup.
> You need to test reality. Instead of mocking, invest in end-to-end (E2E) testing.
"Easily" is like "just." The ease or difficulty is relative to skill, time, team size, infrastructure, and so on.
As for testing reality, sure. But there's also a place for unit tests and partial integration tests.
In some situations, mocking makes sense. In others, full E2E testing is better. Sometimes both might make sense in the same project. Use the right tool for the job.
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.
1 reply →
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.
The only challenge I have encountered with Postgres template [0] databases over the years, is depending on the test framework to get a random name for the database and then inject that random name into the connection URL. Always found a solution though.
[0] https://www.postgresql.org/docs/current/manage-ag-templatedb...