Proposal: tests should only bind to the hooks added before them

[link89]

Let's get started with code sample

import test from 'ava';


// Section One
test.beforeEach( async t => {
  t.log(`before each ${t.title}`);
});

test.afterEach( async t => {
  t.log(`after each ${t.title}`);
});

test('test 1-1', async (t) => {
  t.log(`running ${t.title}`);
  t.pass();
});

test('test 1-2', async (t) => {
  t.log(`running ${t.title}`);
  t.pass();
});

// Section Two
test.beforeEach( async t => {
  t.log(`anther before each ${t.title}`);
});

test.afterEach( async t => {
  t.log(`anther after each ${t.title}`);
});

test('test 2-1', async (t) => {
  t.log(`running ${t.title}`);
  t.pass();
});

test('test 2-2', async (t) => {
  t.log(`running ${t.title}`);
  t.pass();
});

(see also: https://github.com/link89/ava-demo/blob/master/03-hooks.test.ts)

Current Behavior

2 beforeEach & afterEach hooks are applied for all cases.

I don't think this is very useful design.
This behavior may be a nice-to-have feature, but definitely not an essential one.
Because we can always achieve the same purpose using different ways.

Suggested Behavior

Each case should only bind to the one beforeEach & afterEach hooks that are defined before them.

By implement the hooks this way will make it possible to define different pre-condition in a single file.
And the reason to put all cases into single files is that we need to share states & resources (like web sessions, webdriver handlers), which is hard to implement in a multiple processes concurrency model.

And it will also be useful to implement coroutine based concurrency instead of process one.
https://github.com/link89/ava-demo/blob/master/02-coroutine-based-concurrency.test.ts

[novemberborn]

I've been experimenting with a way to get a new test() function, which would indeed have its own hooks. So then yes you could have a test() for specific things — I would use that a lot in service-level integration test I write, where I actually launch the service as a child process.

You can follow along in #2435. The work has stalled a bit though, unfortunately.

Your specific proposal is too different from what we've done before and from what users are familiar with from other test runners. But I think #2435 will deliver what you're looking for.

(I'm closing this issue for housekeeping purposes, but let's keep the conversation going.)