3 ms·

> Amazing for testing. All of our backends tests use a fully independent Postgres database managed by Bazel. It's really nice not having to worry about shared s

> Amazing for testing. All of our backends tests use a fully independent Postgres database managed by Bazel. It's really nice not having to worry about shared state in databases across tests. I would love to know more about this. We use bazel and Postgres, but there is no Postgres isolation between tests currently which is very predictably a large source of flakyness, and also a blocker for increasing test parallelism. I’ve been scheming on perhaps using pg_tmp orchestrated outside of bazel, but if there’s a way to do everything in bazel that would make the transition way easier.

jvolkman 4y ago
Not OP, but we start small postgres instances in our Python tests with some py.test fixtures. The actual postgres binaries are provided by Bazel, so nothing relies on outside installations. I posted this gist a while ago: https://gist.github.com/jvolkman/6e61c52d953677f66f32d8f77b157e61 https://gist.github.com/jvolkman/6e61c52d953677f66f32d8f77b1... That said, this requires one postgres instance for each test, which is pretty heavy. So we keep our tests pretty coarse at the Bazel level (i.e. one Bazel test is actually 10+ Python tests). I've thought about other approaches, such as using a Bazel persistent worker to wrap test execution and manage a single Postgres instance with empty databases created from templates, but never got around to trying anything.
- hamandcheese 4y ago
  Nice, this seems a lot simpler than I thought. Nice tip on embedded-postgres-binaries (https://github.com/zonkyio/embedded-postgres-binaries https://github.com/zonkyio/embedded-postgres-binaries).
sa46 4y ago
Old comment with some details: https://news.ycombinator.com/item?id=28472062 https://news.ycombinator.com/item?id=28472062 In addition to the techniques in the linked comment, I'm currently investigating managing the entire Postgres data dir as a Bazel output directory. That way, we avoid executing the schema for every test. Instead, we'd start a new Postgres cluster against the existing data dir without re-executing the schema or creating from a template DB.

jvolkman 4y ago

Not OP, but we start small postgres instances in our Python tests with some py.test fixtures. The actual postgres binaries are provided by Bazel, so nothing relies on outside installations. I posted this gist a while ago: https://gist.github.com/jvolkman/6e61c52d953677f66f32d8f77b157e61 https://gist.github.com/jvolkman/6e61c52d953677f66f32d8f77b1... That said, this requires one postgres instance for each test, which is pretty heavy. So we keep our tests pretty coarse at the Bazel level (i.e. one Bazel test is actually 10+ Python tests). I've thought about other approaches, such as using a Bazel persistent worker to wrap test execution and manage a single Postgres instance with empty databases created from templates, but never got around to trying anything.

hamandcheese 4y ago
Nice, this seems a lot simpler than I thought. Nice tip on embedded-postgres-binaries (https://github.com/zonkyio/embedded-postgres-binaries https://github.com/zonkyio/embedded-postgres-binaries).

sa46 4y ago

Old comment with some details: https://news.ycombinator.com/item?id=28472062 https://news.ycombinator.com/item?id=28472062 In addition to the techniques in the linked comment, I'm currently investigating managing the entire Postgres data dir as a Bazel output directory. That way, we avoid executing the schema for every test. Instead, we'd start a new Postgres cluster against the existing data dir without re-executing the schema or creating from a template DB.