Mocha-like root hooks for test runner

[ericfortis]

What is the problem this feature will solve?

Currently, before and after outside a describe run on every file, so projects that could have a global setup and teardown, such as server, database, or puppeteer browser, could run tests faster by executing a global before and after only once.

What is the feature you are proposing to solve the problem?

Ensuring before and after outside any test run only once, similar to Mocha Rook Hooks

What alternatives have you considered?

Alternatives:

1. As is. It works, but it could be faster
2. mocha

[avivkeller]

Could you write an example (demo code) of what you are looking for vs what is provided?

Edit: Didn't mean to self assign, meant to apply test_runner label.

[ericfortis]

my-dir/setup.js

import { before, after } from 'node:test'

before(() => {
  console.log('LAUNCH my server only once')
})
after(() => {
  console.log('CLOSE my server only once')
})

my-dir/foo.test.js

import { equal } from 'node:assert/strict'
import { describe, it } from 'node:test'

describe('foo', () => {
  it('1 is 1', () => equal(1, 1))
})

my-dir/bar.test.js

import { equal } from 'node:assert/strict'
import { describe, it } from 'node:test'

describe('bar', () => {
  it('2 is 2', () => equal(2, 2))
})

node --test --import ./setup.js

Its output shows that the before and after hooks get executed on every file.

LAUNCH my server only once
CLOSE my server only once
▶ bar
  ✔ 2 is 2 (0.349167ms)
▶ bar (0.671375ms)
LAUNCH my server only once
CLOSE my server only once
▶ foo
  ✔ 1 is 1 (0.367583ms)
▶ foo (0.696583ms)
ℹ tests 2
ℹ suites 2
ℹ pass 2
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 65.239458

The feature I propose is that before and after hooks that are outside describe run only once, similar to Mocha's global hooks.

Desired output:

LAUNCH my server only once

▶ bar
  ✔ 2 is 2 (0.349167ms)
▶ bar (0.671375ms)
▶ foo
  ✔ 1 is 1 (0.367583ms)
▶ foo (0.696583ms)
ℹ tests 2
ℹ suites 2
ℹ pass 2
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 65.239458

CLOSE my server only once

[avivkeller]

Correct me if I'm wrong, but wouldn't that be the same just running code before your test and then after without the use of hooks?

[ericfortis]

@redyetidev That example yes. Here's one that exports something (a browser page instance) from the setup to the tests.

my-dir/setup.js

import { launch } from 'puppeteer'
import { before, after } from 'node:test'

let browser, page

before(async () => {
  console.log('LAUNCH puppeteer only once')
  browser = await launch()
  page = await browser.newPage()
})
after(() => {
  console.log('CLOSE puppeteer only once')
  browser?.close()
})

export default { page }

my-dir/foo.test.js

import { ok } from 'node:assert/strict'
import { describe, it } from 'node:test'
import P from './setup.js'

describe('foo', () => {
  it('foo', () => ok(P.page.setViewport))
})

my-dir/bar.test.js

import { ok } from 'node:assert/strict'
import { describe, it } from 'node:test'
import P from './setup.js'

describe('bar', () => {
  it('bar', () => ok(P.page.setViewport))
})

[avivkeller]

CC @nodejs/test_runner

---

IMO theres not too much benefit to this feature, as it's pretty-much the equivalent of

runStuffBeforeTesting()
test() / run() / ...
runStuffAfterTesting()

But WDYT?

[ericfortis]

The benefit I propose is just speed, consider that runStuffBeforeTesting could be slow, such as launching puppeteer. Multiply that by 200 tests.

[ljharb]

it sounds like you want a beforeAll, if before is actually beforeEach already?

[avivkeller]

it sounds like you want a beforeAll, if before is actually beforeEach already?

I just don't see the benefit of that versus writing code before and after running tests? But it does seem like that's what is being asked.

[ericfortis]

@ljharb
Yes, a beforeAll, or a context-sensitive before.
Currently, a before in or outside a describe suite makes no difference. In Mocha, if it's outside a describe it's a root hook.

---

@redyetidev
Consider a setup that exports an instance, such as the second example. In that case, reusing the browser-page on every test saves a significant amount of time. I agree there's no functional benefit to this proposal, it's just a speed one.