6 ms·

I think I saw an Uber-engineer's presentation (YouTube; can't find it now anymore) about their test environment having the ability to automatically fork the dat

I think I saw an Uber-engineer's presentation (YouTube; can't find it now anymore) about their test environment having the ability to automatically fork the database for every new test run, such that they could easily "revert" (in their case ignore/walk away from) the database after a test run. I find that an appealing idea, since regular test runs in the places where I work, tend to create cruft data in the test enviroment that is lopsided and voluminous in ways that do not properly represent the production system anymore. (And no one wants to troubleshoot performance issues that only ever exist in the test environment.) I have to imagine that pg_branch might be part of building a solution similar to this? Could people speak to some practical applications for this? Maybe I'm thinking about entirely the wrong one here...

Zanfa 3y ago
A common pattern in Ruby-world is running each test case in a database transaction that is rolled back. A simple way to keep a clean slate in your test database.
- vb-8448 3y ago
  It's also quite common in python and I guess in any other language. It's great for unittests, but not suitable for integration or end-to-end tests.
- sverhagen 3y ago
  Been there, done that, but please beware, this means that you're missing out on some nuanced behaviors that you would get if your subject under test would actually commit the transaction. I moved away from this entirely. A more-reliable setup is to let the test commit real transactions, and cleanup afterwards. You might be able to do that by calling "delete" on all repository instances, in the tearDown method of your tests. Or you could use something like Flyway to reset and reinitialize the database entirely before every test. That sounds expensive, and it certainly depends on the kind of project we're talking, but if this is a moderately-sized microservice, and you're running tests scoped to just that microservice, the setup shouldn't be too crazy, and this may actually run pretty smooth. (We run our database in a Testcontainers instance.)
petepete 3y ago
> about their test environment having the ability to automatically fork the database for every new test run, such that they could easily "revert" (in their case ignore/walk away from) the database after a test run I think this should be really straightforward by using one database as a template for another. This is how Postgres's create database works and it defaults to Template1 https://www.postgresql.org/docs/current/manage-ag-templatedbs.html https://www.postgresql.org/docs/current/manage-ag-templatedb...
- jasfi 3y ago
  The intention of pg_branch is to optimize this process. They mention two problems: 1. The template database can't have active connections during the CREATE DATABASE process. 2. The CREATE DATABASE from a template database can be slow for large DBs.
  - ilyt 3y ago
    > The template database can't have active connections during the CREATE DATABASE process. Why would that be a problem ?
    - dalore 3y ago
      If you are trying to branch prod (or even a staging db) then you can't
      - ComputerGuru 3y ago
        Right. But the obvious solution is to just not do that. Create a template and base production/staging off it, then use that template. Or use the same bootstrap/migration process to create the template as you do staging. Regular tests shouldn’t assume access to staging/prod, anyway.
        conceptme 3y ago
        So how do you test your migration? Will work fine with 10 records but perhaps not with 10 million.
vasco 3y ago
We have something like this with gitlab "review apps". Each MR launches an env with its own db that applies migrations and fake data inserters, so each MR has its own db at current state of MR.
prpl 3y ago
Salesforce does this for customers: https://developer.salesforce.com/blogs/2022/09/sandboxes-on-hyperforce-quick-clone-is-generally-available https://developer.salesforce.com/blogs/2022/09/sandboxes-on-...

Zanfa 3y ago

A common pattern in Ruby-world is running each test case in a database transaction that is rolled back. A simple way to keep a clean slate in your test database.

vb-8448 3y ago
It's also quite common in python and I guess in any other language. It's great for unittests, but not suitable for integration or end-to-end tests.
sverhagen 3y ago
Been there, done that, but please beware, this means that you're missing out on some nuanced behaviors that you would get if your subject under test would actually commit the transaction. I moved away from this entirely. A more-reliable setup is to let the test commit real transactions, and cleanup afterwards. You might be able to do that by calling "delete" on all repository instances, in the tearDown method of your tests. Or you could use something like Flyway to reset and reinitialize the database entirely before every test. That sounds expensive, and it certainly depends on the kind of project we're talking, but if this is a moderately-sized microservice, and you're running tests scoped to just that microservice, the setup shouldn't be too crazy, and this may actually run pretty smooth. (We run our database in a Testcontainers instance.)

petepete 3y ago

> about their test environment having the ability to automatically fork the database for every new test run, such that they could easily "revert" (in their case ignore/walk away from) the database after a test run I think this should be really straightforward by using one database as a template for another. This is how Postgres's create database works and it defaults to Template1 https://www.postgresql.org/docs/current/manage-ag-templatedbs.html https://www.postgresql.org/docs/current/manage-ag-templatedb...

jasfi 3y ago
The intention of pg_branch is to optimize this process. They mention two problems: 1. The template database can't have active connections during the CREATE DATABASE process. 2. The CREATE DATABASE from a template database can be slow for large DBs.
- ilyt 3y ago
  > The template database can't have active connections during the CREATE DATABASE process. Why would that be a problem ?
  - dalore 3y ago
    If you are trying to branch prod (or even a staging db) then you can't
    - ComputerGuru 3y ago
      Right. But the obvious solution is to just not do that. Create a template and base production/staging off it, then use that template. Or use the same bootstrap/migration process to create the template as you do staging. Regular tests shouldn’t assume access to staging/prod, anyway.
      - conceptme 3y ago
        So how do you test your migration? Will work fine with 10 records but perhaps not with 10 million.

vasco 3y ago

We have something like this with gitlab "review apps". Each MR launches an env with its own db that applies migrations and fake data inserters, so each MR has its own db at current state of MR.

prpl 3y ago

Salesforce does this for customers: https://developer.salesforce.com/blogs/2022/09/sandboxes-on-hyperforce-quick-clone-is-generally-available https://developer.salesforce.com/blogs/2022/09/sandboxes-on-...