pglite VS dockertest

Hey HN! For a few months, I've been building pgmock at work for our E2E and unit test suite. It emulates Postgres in WebAssembly and has full feature parity with production databases.

The cool thing about it is that you don't need any external processes or proxies. If your platform can run WASM (Node.js, browser, etc.), it can probably run pgmock. Creating a new database with mock data is as simple as creating a JavaScript object.

It's a bit different from the amazing pglite [1] (which inspired me to open-source pgmock in the first place). While pgmock runs an x86 emulator, pglite compiles a Postgres fork to native WASM directly and is hence much faster and more lightweight. However, it only supports single-user mode and a select few extensions, so you can't connect to it with normal Postgres clients (which is quite crucial for E2E testing).

Theoretically, it could be modified to run any Docker image on WebAssembly platforms. Anything specific you'd like to see?

Happy hacking!

[1] https://github.com/electric-sql/pglite

I've found postgres via docker to be fine for dev and testing, but there are various epheremal postgres scripts, plus this could be promising for node stuff https://github.com/electric-sql/pglite if it works out. I'd imagine if this does work out we'll see the same kind of builds for other runtimes as well (like python)

> Use SQLite for everything, or Postgres if you outgrow it.

Or both! ElectricSQL syncs front end SQLlite back to server side postgres. And they just rebuilt postgres on pure WASM (https://github.com/electric-sql/pglite). All ties together with a CRDT.

I'm not affiliated, but just think it's just cool to imagine calls to front end sqllite as the be-all-end-all.

I am using https://github.com/ory/dockertest for tests, specifically for databases. Is there any advantage to use Testcontainers?

Now, let's run the tests. For this purpose, we are going to use dockertest, but test containers is also a good solution.

During my path learning go so far I have come across some amazing libraries and utilites, one of my favourite for integration testing is dockertest.

Things I can't live without in a new Go project in no particular order:

- https://github.com/golangci/golangci-lint - meta-linter

- https://goreleaser.com - automate release workflows

- https://magefile.org - build tool that can version your tools

- https://github.com/ory/dockertest/v3 - run containers for e2e testing

- https://github.com/ecordell/optgen - generate functional options

- https://golang.org/x/tools/cmd/stringer - generate String()

- https://mvdan.cc/gofumpt - stricter gofmt

- https://github.com/stretchr/testify - test assertion library

- https://github.com/rs/zerolog - logging

- https://github.com/spf13/cobra - CLI framework

FWIW, I just lifted all the tools we use for https://github.com/authzed/spicedb

We've also written some custom linters that might be useful for other folks: https://github.com/authzed/spicedb/tree/main/tools/analyzers

I've used dockertest a bunch and it is really amazing.

Reminds me of https://github.com/ory/dockertest

If your project is relatively simple and you can get away with recreating your scenarios against a real mock database and run other related services locally. It would be good to setup docker containers for your test scripts and write e2e tests. I believe e2e tests are harder but more useful in understanding/reasoning how users are impacted.

Just a heads up, the repository in your comment is invalid, the correct link is https://github.com/ory/dockertest

Don't mock. Use https://github.com/ory/dockertest to actually run tests against a dockerized DB.

Use a library like ory/dockertest to spin up a test database for integration tests. It's easy to use, and tests are still fast. It'll take a minute to download the mysql docker image the first time. But, once it's been downloaded, starting the db, running migrations, and running the tests is still pretty quick.