Native node TestContext.assert is not typed correctly

[wjaspers]

🔎 Search Terms

NodeJS 22
Typescript 5.5.4
test runner
assertions

🕗 Version & Regression Information

• This changed between versions 3.6.3 and 5.5.4
• I was unable to test this on prior versions because the Test runner was introduced as experimental in Node 18, and was made stable in Node 20.

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/PTAEAsBdIBwZwFwgHYHsAmBTAVnAdKgE4Dmw6qAxnMADYCGkmckwdMAlsI83lALY0AxBVTJGAD0h04cTIUgAodnxhFIoAN6hu6gL6gAZoVR9QAcjRYEOswG4FCkKABCxgNaZkCnQAozNgBpQH0gASlAAXgA+TQVQbTxpWXk8ZkJ2CkgAUQBHAFc6GhDCPMwgyBLMUPtdaodlVXlNUAAVJkgAYVEJPUNjUwsMTGt2uwcnAHUiN3ZkYm92v0DgyARW9q6xTElw6Nj4yESZOUO0jOz8wuLS8sq62tsgA

💻 Code

// https://nodejs.org/docs/latest/api/test.html#contextassert
import { test } from 'node:test';

// Broken
test('test', (t) => {
  t.assert.strictEqual(true, true);
});

import { TestContext } from 'node:test';

// Working
test('test', (t: TestContext) => {
  t.assert.strictEqual(true, true);
});

🙁 Actual behavior

Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
input.tsx(5, 15): 't' needs an explicit type annotation.
(property) TestContextAssert.strictEqual: (actual: unknown, expected: true, message?: string | Error) => asserts actual is true
Tests strict equality between the actual and expected parameters as determined by Object.is().

import assert from 'node:assert/strict';

assert.strictEqual(1, 2);
// AssertionError [ERR_ASSERTION]: Expected inputs to be strictly equal:
//
// 1 !== 2

🙂 Expected behavior

// Both cases should be treated the same way.
test('test', (t) => {
t.assert.strictEqual(true, true);
});

test('test', (t: TestContext) => {
t.assert.strictEqual(true, true);
});

Additional information about the issue

Test example taken directly from NodeJS 22 documentation
https://nodejs.org/api/test.html#contextassert

[MartinJohns]

This is working as intended per #32695. Assertions require every name in the call target to be declared with an explicit type annotation.

[fidian]

I've got three questions.

1. Every name in the call target needs to be declared with an explicit type annotation. TypeScript knows the types involved. Why does the parameter need to be explicit? I've read the issue and others like it but I failed to find the underlying reason why explicitly typed parameters are required or a workaround.

2. Why does the native assert package work?

TypeScript Playground

3. Using the native assertions doesn't help with the test plan when one is required. Can @types/node be updated so the first example works? If so, is that a ticket for DefinitelyTyped/DefinitelyTyped?

I appreciate any extra detail or dumbing-down of the information that you can provide.

[MartinJohns]

1. This limitation is by design for performance reasons.
2. This library does not require your passed function to be an assertion function, or there are no identifiers without declared type (didn't check which one).
3. That would be a bad change. I'm sure it's intentional that it requires an assertion function.

[typescript-bot]

This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[daviduzumeri]

I don't think this is a TypeScript issue per se, but it is weird that this works when node:assert is imported directly, but it doesn't when it's used off of node:test's TestContext object which, as far as I know, just re-exports node:assert.

[daviduzumeri]

I expect this is an issue with @types/node instead and how it's typing TestContext's assert:

Note when it's off of node:assert it's a full function, but it's a lambda when it's on TestContext.