Hacker News Reader

Comment by brushfoot | Hacker News Reader

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.

View on HN

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.

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.

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.

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)

> 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.

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...

Reply on news.ycombinator.com