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

Ephemeral Postgres Databases

eradman.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Ephemeral Postgres Databases

#21

Post by hardwaresofton »

This is one of the areas that docker fits perfectly. Run your application with software that runs in docker containers (pg, redis, minio), and run them all for real when you test flows that require them.

I do this and for “heavier” services that support some form of isolation/multi-tenancy (ex. Postgres) I use per-test databases(or whatever unit of isolation).

To cap all of this off, when you build your abstractions, build in the notion of clearing the backing store (and make sure you can only run that in test environments), and lots of things become much easier to simulate.

This approach works across languages, backing services (assuming they’re not cloud only), and testing frameworks.

I wrote a now relatively old post about it[0]

[0]: https://vadosware.io/post/a-recipe-for-running-containers-in...

Re: Ephemeral Postgres Databases

#23

Post by [deleted] »

hardwaresofton wrote: post #21

This is one of the areas that docker fits perfectly. Run your application with software that runs in docker containers (pg, redis, minio), and run them all for real when you test flows that require them. I do this and for “heavier” services that support some form of isolation/multi-tenancy (ex. Postgres) I use per-test databases(or whatever unit of isolation). To cap all of this off, when you build your abstractions,…

[deleted]

Re: Ephemeral Postgres Databases

#25

Post by jschrf »

hardwaresofton wrote: post #21

This is one of the areas that docker fits perfectly. Run your application with software that runs in docker containers (pg, redis, minio), and run them all for real when you test flows that require them. I do this and for “heavier” services that support some form of isolation/multi-tenancy (ex. Postgres) I use per-test databases(or whatever unit of isolation). To cap all of this off, when you build your abstractions,…

Totally! Docker Compose is so useful for this.

I want my tests to talk to a real DB, or a real MQ, or a real instance of a service, because that's what the software does in real life. Running tests themselves inside of containers with access to the other services is good practice IMHO.

So what if a connectivity issue or some esoteric SQL thing explodes some rigorous test on a specific, seemingly-unrelated business function. In fact, I want that to happen. I want to discover failure modes and anomalies sooner than later, and to simulate real-world conditions.

The idea of mocks and stubs, and puritanical testing of things in complete isolation seems counterproductive to me. Why do people bother putting effort into abstracting away the most important components of their systems?

Imagine driving a car where every component was rigorously tested in isolation but never as a whole? It would be a disaster. Sometimes it seems like this is how teams approach testing. See the recent NPM registry issue where the integration of a few microservices led to a disastrous security issue.[0]

On my own projects, I go so far as to not even clearing my test database between tests, unless it's called for. Why? It surfaces bugs that are otherwise easy to miss in testing against a pristine database.

[0]: https://github.blog/2021-11-15-githubs-commitment-to-npm-eco... (second issue, Nov. 2)

Re: Ephemeral Postgres Databases

#26

Post by jschrf »

switchbak wrote: post #16
latch wrote: post #11

> For some time proponents of unit testing have asserted that unit tests should not touch a real database Is that still a belief in some circles? I feel like the shift away from this started like 15 years ago (largely because of RoR in my mind). Anyways, this essentially launches a pg instance with a postgresql.conf that is aimed for speed (at the risk of possible data loss/corruption). DO NOT DO THIS IN PRODUCTION,…

For real _unit_ tests? I would argue it's still a good distinction. We use an embedded postgres in our DB tests, and we call those 'Integration Tests' and run them separately than the pure unit tests. While still tremendously valuable, they do take a bit longer to run, and currently aren't written to allow parallel tests running. We've had a typical habit of writing most tests that hit the DB. Since applying a bit mo…

Aside from testing framework concurrency limitations, why wouldn't you allow parallel tests?

If your running system speaks to the DB in parallel and handles pre-existing data, why wouldn't you want your tests to do the same?

Re: Ephemeral Postgres Databases

#29

Post by nathanwallace »

Steampipe [1] is an open source CLI to query cloud APIs (e.g. AWS, GitHub, Kubernetes) with SQL. It uses an embedded Postgres instance internally and is built with Foreign Data Wrappers.

We install and leverage the Zonky Embedded Postgres Binaries [2] which are normally used for test suites. They have been great for us.

It's amazing how fast and light Postgres runs for these use cases!

1 - https://steampipe.io 2 - https://github.com/zonkyio/embedded-postgres-binaries

Re: Ephemeral Postgres Databases

#30

Post by piperswe »

mborch wrote: post #5
pquerna wrote: post #4

Earlier quoted context omitted.

At a $previous_job I basically also did what the post is describing. The "best" thing we did was actually using a "template database": https://www.postgresql.org/docs/14/manage-ag-templatedbs.htm... We would start a Postgres Process. We would create a new database, run all of our migrations and basic data bring up. Then we would create a new Database per Test Suite, using the one we just ran migrations as the Templat…

That's probably more or less the same thing in terms of what actually happens in PostgreSQL. All things considered, an actual database probably gives you the least gray hair, but with some careful test setup I have had good success using the savepoint/rollback trick (and it trivially supports nested fixtures as well).

With multiple databases you get the advantage of being able to run tests in parallel, so even though they might be the same under the hood they offer interfaces that suit quite different use cases
Post reply on HN