Sharing database connections across test workers

[osdiab]

In my company we're writing integration tests that connect to real database instances. We'd like to do this with ava, and from the very old issue #472 , it seems the suggestion is to set up fixtures/open a new database connection for each test file individually (which I presume means that within a single test file tests happen serially?). I could switch our test db setup to happen once per test file - but i'm wondering if it's possible to save the overhead of doing that and instead do something once per worker?

in the status quo, i've hacked together a jest setup that sets up one database per test worker to achieve this performantly. it uses a jest test run setup script that relies on its JEST_WORKER_ID environment variable + the maxWorkers config variable in setup scripts, to spin up a single db instance per worker thread, taking advantage of the fact that within a single worker (including across files) tests are not run concurrently. within a test we can do stuff like clear out the db between tests because each worker is isolated, both in JS and also in database connection.

I'd rather switch to ava though, so if i do that I'd need to benchmark how much setting up a separate db per file would harm db test run perf because i'd have to create a new postgres database from a common template db for each test file (besides dev time to change to this paradigm). Does ava have similar environment variables/setup test functionality that I could potentially use to reuse the existing "1 db per worker" logic?

EDIT: seems that the require config array would be a reasonable place to put worker setup, though printing out the environment looks like ava includes nothing in there for knowing the number of workers / current worker. does the setup script happen once per worker? maybe i can make a test db tagged by that random value, save that to a global variable, and then access it from within tests, that could work potentially?

hard to find docs for stuff like this that plays around with the internals of the library. or alternatively, does the recent shared workers functionality provide a potential alternative? though sounds like that'd be more like making one shared db that all the parallel workers would have to share, like taking turns grabbing a mutex to access it; sounds not great so probably not that lol #2605

but yeah half of me is asking this to save developer and test runtime, and half of me is asking this to better understand how exactly ava's concurrency model/configuration works. thanks for bearing with me!

[novemberborn]

Does ava have similar environment variables/setup test functionality that I could potentially use to reuse the existing "1 db per worker" logic?

The worker processes do not know which of how many processes they are. And each test file runs in a new worker process, so launching the database instance at that level isn't ideal in terms of overhead.

Shared workers would be a better approach but work needs to be done. Would be great if you could start a worker through the AVA config, and it would know the max concurrency, so it can allocate database instances and then let test workers request the connection URL.

I presume means that within a single test file tests happen serially?

test is concurrent, but test.serial is serial.