Interesting. If I'm understanding this correctly you're proposing a "helper worker" that AVA manages for you, and that can expose some config that test workers can read.

Yes, exactly. Helper worker is an even better name for it.

It will make AVA more scalable in the sense that I don't have to consolidate a bunch of assertions into a single test case just to avoid the extra overhead.

Setting up API servers for each test also takes a while; most of the time I want to wait for certain connections to be made before I start listening, adding startup time to each test case. If I could do this once per run, that would cut down test run time dramatically.

I still think this would be a great thing to have. But I'd like to propose a minor tweak: Optional concurrency limits for access to the resource:

• The access to the resource in a test would be async and would require await. That async access would block if the concurrency limit was reached, waiting until the resource was available again. E.g. changing the OP's example to:

  test('GET /todos', async (t) => {
    const client = axios.create({ baseURL: await t.resource('serverHost') })
    const { data } = await client.get('/todos')
    t.true(data.length > 0)
  })

• The code that sets up the resource would be able to optionally specify a concurrency limit. E.g. modifying the OP's example, this could be done as:

  // This runs before any other test processes have been spun up
  test.resource('Set up API server', async (t) => {
    const server = (await createServer()).listen()
    const host = `http://127.0.0.1:${server.address().port}`
  
    // Only JSON-serializable values can be provided to test processes
    t.provide('serverHost', host, { concurrency: 8 })
  
    return async function dispose () {
      // When all tests are done, dispose of the resource
      server.close()
    }
  })

  At the risk of bikeshedding, I've also changed t.resource here to t.provide to avoid overloading with t.resource in the test.

  More bikeshedding could include: whether specifying the concurrency belongs in the config file/CLI rather than in the setup code; whether there should be an easy way to set it to relative to the number of CPU cores; and whether a concurrency limit should be enabled by default for all such resources.

(See also discussion at #2048 (comment))

Sounds great. Would you have time to work on this stuff @ronen?

Would you have time to work on this stuff @ronen?

Would love to, but sadly very unlikely to find the time. At least not for the forseeable future. 😞

I think this is a great start. I've been looking for well integrated solutions to a similar resources issue we have in our test harness. The interesting thing about this solution is that it's simple to implement (given the JSON serialization and static nature of the data passed to workers). However, it also limits the capabilities.

Currently, each of our test create a new cassandra keyspace and initializes our schema (like a database / table space in SQL + creating the schema). Unfortunately, this operation is somewhat (surprisingly) costly. Using pre-test resource initialization would allow us to create a keyspace pool prior to starting the tests (most likely feeding off of the -c argument to know how many keyspaces to create). The problem is that we'd need inter-process communication for each test or each worker to request and lock a keyspace.

I understand that this would add a lot of complexity to AVA. Maybe someone can suggest a better (simpler) approach. Our short-term solution is a per-file keyspace pool.

@lewisdiamond wrote:

Using pre-test resource initialization would allow us to create a keyspace pool prior to starting the tests (most likely feeding off of the -c argument to know how many keyspaces to create). The problem is that we'd need inter-process communication for each test or each worker to request and lock a keyspace.

Very good point! The API described in the earlier comment allows the resource creator to provide the same value to each client. But a resource creator should be able to provide a different value to each client from a pool of precomputed values or, more generally, generating values dynamcally. I think it would be possible to handle that keeping the above API but with options to t.provide() to support different scenarios. Perhaps something like:

// Provide a shared JSON-serializable value `host` to up to 8 parallel clients
t.provide('serverHost', { 
 value: host,
 concurrency: 8,
}) 

// Provide a JSON-serializable value from a pool, to up to 8 parallel clients
t.provide('keyspace', {
 pool: [{ host, key: key1 }, { host, key: key2 }, ..., { host, key: key8 }],
})

// Specify a `create` function that creates a JSON-serializable value to provide
// to a client upon request, with up to 8 parallel clients.  When a client finishes,
// the optional `release` function will be called with that same value, allowing
// the resource provider to tidy up as necessary.
t.provide('workspace', { 
   create: workspaceCreator,
   release: workspaceCloser,
   concurrency: 8,
}) 

Of course with a general create/release mechanism, the others are just convenient shorthands:

// Provide a shared value
t.provide('serverHost', { 
  create: () => host,
  concurrency: 8,
})

// Provide values from a pool
const pool = [{ host, key: key1 }, { host, key: key2 }, ..., { host, key: key8 }]
t.provide(`keyspace`, {
  create: () => pool.pop(),
  release: val => pool.push(val),
  concurrency: pool.length,
})

Also, to be able to provide a resource per test file rather than per test as per this issue, the API should allow getting a resource in a .before() hook:

test.before(t => {
  t.context.keyspace = t.resource('keyspace')
})

where the resource will automatically be released when all tests in the file finish.

[And sorry, I still don't have time to actually implement this. Just kibbitzing... 😞 ]

Minor additional thought on the proposed API: In the above examples, AVA doesn't know about the serverHost keyword until after the server has successfully spun up and t.provide() is called, making it hard for AVA to administer the resources.

Instead, I think the resource keyword should be supplied to test.resource() rather than to t.provide():

test.resource('myServer', async (t) => {
  const server = (await createServer()).listen()
  const host = `http://127.0.0.1:${server.address().port}`
  t.provide({ value: host, concurrency: 8 })
  return async function dispose () {
    server.close()
  }
})

This way:

• As soon as AVA executes all the test.resource() methods, it will immediately know all the resource keywords. It wouldn't need to wait for the async resource definition methods to resolve, it could leave them running asynchronously and start executing the tests

• When a test calls await t.resource(keyword), AVA will know immediately if no such resource were defined, and could immediately fail. Otherwise it would block until that resource calls its t.provide() method.

• The configuration files/CLI could allow configuration for specific resource to be keyed by its keyword. E.g. something like:

  {
     "resources": {
         "myServer": { 
                 "concurrency": 4,
                 "params": { "...": "arbitrary data" }
          },
     }
  }

  And then the execution context (t param) to the resource definition could include that configuration info, allowing const server = (await createServer(t.params)).listen() or whatever.

This is good idea! Let's say, it's very useful for running Nuxt.js server with all required modules (specified in nuxt.config.js) for test purposes and disposing of it.

I've made a little memo on how I would set up Nuxt.js server with Ava's test.resource: nuxt/typescript#293 (comment)

AVA now has experimental shared worker support. Code runs in a worker thread, in the main process, and can communicate with test workers.

The proposals made in this issue could be implemented using this infrastructure. Please join us in #2605.