Example code from docs results in 'failed running afterEach hook'

[markwylde]

Version

v18.8.0

Platform

Linux pop-os 5.19.0-76051900-generic ~22.04 SMP PREEMPT_DYNAMIC Thu A x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Create a test.js file anywhere with the contents from the official node docs:
https://nodejs.org/api/test.html#contextaftereach-fn-options

I added imports resulting in the following code:

import test from 'node:test';
import assert from 'node:assert';

test('top level test', async (t) => {
  t.afterEach((t) => t.diagnostics(`finished running ${t.name}`));
  await t.test(
    'This is a subtest',
    (t) => {
      assert.ok('some relevant assertion here');
    }
  );
});

Run the test:

node test.js

How often does it reproduce? Is there a required condition?

Every time

What is the expected behavior?

That the test passes.

What do you see instead?

$ node test.js 
(node:67463) ExperimentalWarning: The test runner is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
TAP version 13
# Subtest: top level test
    # Subtest: This is a subtest
    not ok 1 - This is a subtest
      ---
      duration_ms: 0.001258063
      failureType: 'hookFailed'
      error: 'failed running afterEach hook'
      code: 'ERR_TEST_FAILURE'
      stack: |-
        TestContext.<anonymous> (file:///node18test/test.js:5:24)
        TestHook.runInAsyncScope (node:async_hooks:203:9)
        TestHook.run (node:internal/test_runner/test:483:25)
        TestHook.run (node:internal/test_runner/test:624:18)
        node:internal/test_runner/test:433:20
        async [kRunHook] (node:internal/test_runner/test:431:7)
        async Test.run (node:internal/test_runner/test:493:9)
        async TestContext.<anonymous> (file:///node18test/test.js:6:3)
        async Test.run (node:internal/test_runner/test:484:9)
      ...
    1..1
not ok 1 - top level test
  ---
  duration_ms: 0.003619246
  failureType: 'subtestsFailed'
  error: '1 subtest failed'
  code: 'ERR_TEST_FAILURE'
  ...
1..1
# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0
# duration_ms 0.053296433

Additional information

I'm still not sure if this is an issue with the documentation or a bug with Node. I choose bug with node as it feels like that code should pass.

[markwylde]

I looks like a diagnostics causes the test to fail. Is this expected? It doesn't look like it should from the TAP spec or Node API docs?

The following code works fine:

import test from 'node:test';
import assert from 'node:assert';

test('top level test', async (t) => {
  t.afterEach((t) => {
    assert.ok('ok')
  });
  await t.test(
    'This is a subtest',
    (t) => {
      assert.ok('some relevant assertion here');
    }
  );
});

[MoLow]

I think this was fixed here #44351,
can you confirm changing from diagnostics to diagnostic fixes this at your end as well?

[markwylde]

Hi Yeah @MoLow changing to diagnostic fixes the problem.

But it appears the beforeEach is swallowing the error.

By running the following code:

import test from 'node:test';
import assert from 'node:assert';

test('top level test', async (t) => {
  t.afterEach((t) => {
    t.diagnostics(`finished running ${t.name}`)
  });
  await t.test(
    'This is a subtest',
    (t) => {
      assert.ok('some relevant assertion here');
    }
  );
});

We should have seen:

TypeError: t.diagnostics is not a function
    at TestContext.<anonymous> (file:///node18test/index.js:6:9)
    at TestHook.runInAsyncScope (node:async_hooks:203:9)
    at TestHook.run (node:internal/test_runner/test:483:25)
    at TestHook.run (node:internal/test_runner/test:624:18)
    at node:internal/test_runner/test:433:20
    at async [kRunHook] (node:internal/test_runner/test:431:7)
    at async Test.run (node:internal/test_runner/test:493:9)
    at async TestContext.<anonymous> (file:///node18test/index.js:12:3)
    at async Test.run (node:internal/test_runner/test:484:9)

Should I create a new issue for this?

[MoLow]

@markwylde thanks, that was fixed as well #44284