Repository navigation
Test runner: recursive or globbed loading of non-JS test files #44023
Description
What is the problem this feature will solve?
As per https://nodejs.org/dist/latest-v18.x/docs/api/test.html#test-runner-execution-model, the test runner can be started as node --test dirname/ to recursively run all test files (ending in .js, .cjs or .mjs) contained in the directory dirname. This unfortunately means that non-JS test files, specifically test files written in TypeScript in my case, will not be found since they end in .ts instead of .js. The docs say to provide each test file separately, e.g. node --loader=ts-node/esm --test dirname/foo.test.ts dirname/bar.test.ts but this gets messy very quickly.
What is the feature you are proposing to solve the problem?
I see a few options (in order of my preference, starting with most preferred):
- Support globbing (e.g.,
node --loader ts-node/esm --test "dirname/**/*.ts"). Note that this does work on Linux, to some extent, since the shell will expand asterisks. This doesn't work on Windows, though, and doesn't work when the string is quoted. Tools like mocha will perform globbing independently of the operating system or shell. - Provide a CLI arg for additional test file extensions (e.g.,
node --loader ts-node/esm --test --test-extensions=.ts,.cts,.mts dirname/). - Have some sort of configuration file for the test runner where this can be configured.
- Let loaders tell Node about additional file extensions (e.g.,
node --loader ts-node/esm --test dirname/and ts-node could hook into the directory traversal).
What alternatives have you considered?
- Listing test files manually (hard to maintain)
- Having a script do the globbing and construct the command line with all files explicitly listed
- Running
node --testpointed to an index file that performs the globbing and dynamically imports all actual test files (very ugly; loses process separation between test files)
I also opened an issue at ts-node (TypeStrong/ts-node#1853) specifically for TypeScript, to see if they are interested in better test runner support.
Activity
benjamingr commentedon Jul 28, 2022
@nodejs/test_runner
benjamingr commentedon Jul 28, 2022
Honestly, I would just add
.tssupport explicitly (and probably.tsx/.jsx) given how common it is compared to the alternative with a helpful message in case people didn't pass a loader/require hook.MoLow commentedon Jul 28, 2022
probably for starters, as @benjamingr support
/.tsx?$/as well,eventually allow configuration of custom file filtering
ljharb commentedon Jul 29, 2022
I don’t think supporting ts (or jsx) by default makes any sense if TS/JSX content isn’t auto loaded.
MoLow commentedon Jul 29, 2022
Perhaps we should implement a solution for #43895 (that will allow passing a custom function to filter files)
I am willing to implement some
--test-configflag if there is consensus on it.CC @nodejs/test_runner
aduh95 commentedon Jul 29, 2022
Maybe a better solution would be to have an option for the loader to have an option to tell which file patten it supports for tests? /cc @nodejs/loaders
MoLow commentedon Jul 29, 2022
why will it be better? I think a configuration file will cover more use-cases (real usecases from here), for example:
loaders should process test files regardless of this discussion, there is a seperate issue about that
aduh95 commentedon Jul 29, 2022
Running the test runner on a
.tsfile only makes sense if there's a loader able to understand it, so it's convenient if the loader itself can provide this info. If the info comes from somewhere else, it's more likely to de-sync at some point. Anyway that was just a thought.ljharb commentedon Jul 29, 2022
I completely agree that that’s the only way to handle it. Nothing should be implicitly included unless node understands it;cams adding a loader should also implicitly include anything the loader handles. Users should only have to configure file extensions if they’re deviating from their loaders’ defaults.
MoLow commentedon Jul 29, 2022
I might not fully understand how loaders work, so correct me in case I am wrong - a loader does not expose what file extensions it supports,
So there is no way for
--testto know what to extensions to filterIf we are talking about a new flag/option declaring what extensions a loader supports in the context of running tests - I don't really see a reason that should be part of loaders and not just part of the test runner config?
meyfa commentedon Jul 29, 2022
Personally, I see a huge advantage in letting users specify the file pattern precisely: I often find myself putting test fixtures, shared code etc. in the
test/directory (e.g.test/fixtures.ts), along with test files (such astest/foo.test.ts,test/bar.test.ts). In these cases, I would want to use a glob liketest/**/*.test.tsinstead of basing it off of the.tsextension.cspotcode commentedon Jul 29, 2022
I see mts and cts file extensions were not mentioned above. This is evidence in favor of allowing users and customization hooks to specify.
42 remaining items
test_runner: support programmatically running `--test`
test_runner: support programmatically running `--test`
test_runner: support programmatically running `--test`
test_runner: support programmatically running `--test`
test_runner: support programmatically running `--test`
feat: support programmatically running `--test`
feat: support programmatically running `--test`
test_runner: support programmatically running `--test`