> is that you can use different databases. But no-one uses different databases.
The main selling point to me was that you could write a lot of wicked fast integration tests on top of H2 and exercise your ORM. But that was already at a point where "the testing pyramid" was a diagram that some of your coworkers had seen and were trying to figure out how to explain to everybody else.
So my desire to write fast backend integration tests never lined up with my job responsibilities + opinions on relative test counts.
> The main selling point to me was that you could write a lot of wicked fast integration tests on top of H2 and exercise your ORM
Nowadays in the age of containers you can spin up the database you are using in production easily in a few seconds. Unless you are stuck with using one of the old commercial monsters like Oracle this is not really worth doing anymore.
> Nowadays in the age of containers you can spin up the database you are using in production easily in a few seconds.
Is that a database for ants? At $dayjob “a few seconds” isn’t even enough to send a dump over the network. Which is a moot point anyway because there’s absolutely no way random j dev will get access to all the PII that’s in the production db.
I think the parent pretty clearly meant that you can spin up an instance of the same kind of database used in production. E.g., if you use MySQL in prod, you can spin up a local MySQL docker instance for tests rather than an in-memory not-MySQL option like H2 or SQLite.
The main selling point to me was that you could write a lot of wicked fast integration tests on top of H2 and exercise your ORM. But that was already at a point where "the testing pyramid" was a diagram that some of your coworkers had seen and were trying to figure out how to explain to everybody else.
So my desire to write fast backend integration tests never lined up with my job responsibilities + opinions on relative test counts.