Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Database mocks are not worth it

shayon.dev

Post reply on HN
Print view View original

101–110 of 268 posts

Re: Database mocks are not worth it

#101

Post by thom »

brettgriffin wrote: post #70

I'd be really surprised if most applications that rely on databases can't just use a containerized image of their production database in any environment, including CI. In fact, the only example I can really think of is when the production database can't be Dockerized (e.g. a proprietary SaaS database like BigQuery or Snowflake). I'm working on a project that has ~22,000 tests that operate on Docker container of the s…

Are these parallelised? <3ms overhead for a clean database and test code to interact with it is very good!

Re: Database mocks are not worth it

#102

Post by jcgrillo »

nrr wrote: post #95

I think it's probably worth mentioning that the principal concern for tests should be proving out the application's logic, and unless you're really leaning on your database to be, e.g., a source of type and invariant enforcement for your data, any sort of database-specific testing can be deferred to integration and UAT. I use both the mocked and real database approaches illustrated here because they ultimately focus…

The database is often the thing that enforces the most critical application invariants, and is the primary source of errors when those invariants are violated. For example, "tenant IDs are unique" or "updates to the foobars are strictly serializable". The only thing enforcing these invariants in production is the interplay between your database schema and the queries you execute against it. So unless you exercise these invariants and the error cases against the actual database (or a lightweight containerized version thereof) in your test suite, it's your users who are actually testing the critical invariants.

I'm pretty sure "don't repeat yourself" thinking has led to the vast majority of the bad ideas I've seen so far in my career. It's a truly crippling brainworm, and I wish computer schools wouldn't teach it.

Re: Database mocks are not worth it

#103

Post by binary132 »

I think the sweet spot is simple relational abstractions that do not necessarily depend on a SQL implementation. Those are extremely quick and easy to write unit tests against and to use, and don’t burden the developer. Then the library implementing them can itself be well-tested and straightforward, and even portable to other backing stores. I’m not saying “use an ORM”.

Re: Database mocks are not worth it

#104

Post by javcasas »

btilly wrote: post #6
javcasas wrote: post #2

For tests, first use a real database. If you can't because the database just doesn't want to (ahem mongo ahem) then use a fake. If you can't use a fake, stop lying and use a fake. Mocks for databases are extremely brittle and complicated.

Ahem MongoDB? I must admit, I've never understood what MongoDB's real use case is supposed to be. Whenever I've looked at it, there has always been a better alternative. When I've had to use it, I've had to debug performance problems that wouldn't have existed with alternative solutions. It sounds cool. But running software isn't about sounding cool. A decade ago, it was really clear. As https://aphyr.com/posts/284-c…

Sometimes you cannot choose. Sometimes you are handed down some decisions already made, and reverting them may have a cost the business doesn't want to pay.

Re: Database mocks are not worth it

#105

Post by viccis »

Can anyone here who might know more than me explain the difference between dependency injection and the author's suggested pattern at the end? Is it just the same thing? Seems like that's the most common way I see to isolate external services and stub them for testing.

Re: Database mocks are not worth it

#106

Post by [deleted] »

nrr wrote: post #95

I think it's probably worth mentioning that the principal concern for tests should be proving out the application's logic, and unless you're really leaning on your database to be, e.g., a source of type and invariant enforcement for your data, any sort of database-specific testing can be deferred to integration and UAT. I use both the mocked and real database approaches illustrated here because they ultimately focus…

[deleted]

Re: Database mocks are not worth it

#107

Post by jcgrillo »

computerfan494 wrote: post #45
btilly wrote: post #6

Earlier quoted context omitted.

Ahem MongoDB? I must admit, I've never understood what MongoDB's real use case is supposed to be. Whenever I've looked at it, there has always been a better alternative. When I've had to use it, I've had to debug performance problems that wouldn't have existed with alternative solutions. It sounds cool. But running software isn't about sounding cool. A decade ago, it was really clear. As https://aphyr.com/posts/284-c…

MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonably vendor-neutral and can be run locally, and the data modeling it encourages is both preferential for some people as well as pushes users to avoid patterns that don't scale very well with other models. Whether these things are important to yo…

I prefer MangoDB from an operational standpoint. But I'll concede that, as you point out, MongoDB is after all WebScale.

Re: Database mocks are not worth it

#108

Post by globular-toast »

nwatson wrote: post #66
astine wrote: post #42

Testing against a real database is an example of integration testing. Using mocks is for unit testing. Ideally, you want to do both. Unit testing entails isolating particular components for testing which is important because it let's you be more precise in what exactly you're testing. Using mocks also makes it easier to run automated tests because it means you don't need to have a database or credentials handy during…

Then just use a database for unit testing as well.

Then you get a slow test suite. It's important to have a fast test suite to be able to do proper test driven development (which I still believe is the most efficient and effective way to write software, in general). Unit tests should be near 100% coverage. That means a lot of tests.

Re: Database mocks are not worth it

#109

Post by fweimer »

smackeyacky wrote: post #56
ariofrio wrote: post #39

Earlier quoted context omitted.

Does something like PGlite work for your use case? https://pglite.dev/

You can just simply run postgres, why bother with pglite? postgres installs easily on WSL2 or whatever Linux distribution you're using.

You don't even need to install it. It doesn't take a lot of code to run initdb to create a temporary instance, write a suitable configuration file, launch the postmaster process, and delete the temporary database directory tree after terminating the database after testing is complete. On a not-too-fast Linux system, the time for all that is around half a second. Too much overhead for individual unit tests, but fast enough to run once per test suite run.

Re: Database mocks are not worth it

#110

Post by nrr »

jcgrillo wrote: post #102
nrr wrote: post #95

I think it's probably worth mentioning that the principal concern for tests should be proving out the application's logic, and unless you're really leaning on your database to be, e.g., a source of type and invariant enforcement for your data, any sort of database-specific testing can be deferred to integration and UAT. I use both the mocked and real database approaches illustrated here because they ultimately focus…

The database is often the thing that enforces the most critical application invariants, and is the primary source of errors when those invariants are violated. For example, "tenant IDs are unique" or "updates to the foobars are strictly serializable". The only thing enforcing these invariants in production is the interplay between your database schema and the queries you execute against it. So unless you exercise the…

> The only thing enforcing these invariants in production is the interplay between your database schema and the queries you execute against it."

I'm unsure that I agree. The two examples you gave, establishing that IDs are unique and that updates to entities in the system are serializable (and linearizable while we're here), are plenty doable without having to touch the real database. (In fact, as far as the former is concerned, this dual approach to testing is what made me adopt having a wholly separate "service"[0] in my applications for doling out IDs to things. I used to work in a big Kafka shop that you've almost certainly heard of, and they taught me how to deal with the latter.)

That said, I'd never advocate for just relying on one approach over the other. Do both. Absolutely do both.

> I'm pretty sure "don't repeat yourself" thinking has led to the vast majority of the bad ideas I've seen so far in my career. It's a truly crippling brainworm, and I wish computer schools wouldn't teach it.

I brought up WET mostly to comment that, if there's one place in software development where copying and pasting is to be encouraged, testing is it. I'd like to shelve the WET vs. DRY debate as firmly out of scope for this thread if that's alright.

0: It's a service inasmuch as an instance of a class implementing an interface can be a service, but it opens up the possibility of more easily refactoring to cross over into running against multiple databases later.

Post reply on HN