refactor: use suite/test for hierarchical test structure

[kraenhansen]

This is mainly an alternative suggestion to #50 - feel free to close.

Summary

• Replaces the flat test() calls (from feat: flattern tests allowing --test-name-pattern filter #50) with suite()/test() nesting, restoring hierarchical test output while keeping --test-name-pattern filtering support
• --test-name-pattern matches against both suite names (directories) and test names (files), so filtering works at any level of the hierarchy
• Updates README example to show the simpler suite-level filtering

Motivation

PR #50 flattened all tests into top-level test() calls with path-like names (e.g. js-native-api/test_string/test.js) to enable --test-name-pattern filtering. This works but comes with trade-offs:

• Lost hierarchical output: all tests appear at the same indentation level, making it harder to visually scan results by category
• Lost suite-level timing: with nesting, the test runner reports aggregate duration per suite (e.g. how long all test_string tests took combined), which is lost when tests are flat

Using suite()/test() nesting preserves all of these while still supporting --test-name-pattern — the Node.js test runner matches the pattern against suite names too, running all tests inside a matching suite.

Test plan

• npm run node:test passes (all tests run with hierarchical output)
• NODE_OPTIONS=--test-name-pattern=test_constructor npm run node:test correctly filters to only tests in the test_constructor suite
• NODE_OPTIONS=--test-name-pattern=test_null npm run node:test correctly filters leaf tests across suites

🤖 Generated with Claude Code

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

[bavulapati]

As #50 is merged, do we still need this?

[kraenhansen]

Short answer: Yes. This is an alternative suggestion that I'd like to propose (even with #50 merged) - the description above outlines two reasons I think this is better than the current state of the harness.

[bavulapati]

Short answer: Yes. This is an alternative suggestion that I'd like to propose (even with #50 merged) - the description above outlines two reasons I think this is better than the current state of the harness.

I don't have a strong opinion about this. It would be interesting to see @legendecas perspective.

[legendecas]

There are test files with the same name in different folders, like js-native-api/2_function_arguments/test and js-native-api/3_callbacks/test. I think it is still helpful to be able to filter tests with a path.