Test runner contributions

[richiemccoll]

The test runner in Node is a fantastic addition to core. Once this is stable, this should be the default for testing modern node applications.

As NearForm, we would be glad to help contribute to this area. Please let us know of any additional details about how we can support this.

One thing we noticed was that we couldn't find a working group for @node/test_runner. Is that something that is planned for the future?

cc: @simoneb

[cjihrig]

I don't know if we need a working group (but I wouldn't block it if others think it would be helpful), but there is a @nodejs/test_runner group. You might need to be a collaborator to be able to ping the group.

If you're looking for work, the things I can think of off the top of my head are:

• The list of open issues. For the feature requests specifically, you might want to discuss it before working on it.
• Multi process code coverage.
• Source map support in code coverage.

Others may have more suggestions.

[simoneb]

@cjihrig is there a roadmap for the test runner? Since it's a fairly new area, we see it as a opportunity to make considerable improvements without having to be too deep in the intricacies of other areas of the codebase. That's why we thought it may make sense to have a WG so a roadmap with the major features and milestones could be captured, and issues created from those. Basically we would like to contribute by following a roadmap rather than (or in addition to) addressing arbitrary issues, which we're currently already doing.

The rationale behind this is that we would like to see the Node built-in test runner to quickly reach a feature set comparable that of external libraries such as tap or jest.

[cjihrig]

is there a roadmap for the test runner?

There is not currently a roadmap for the test runner. That is largely also true for Node as a project though. Again, I'm not opposed to a WG or a roadmap, they just don't currently exist.

The rationale behind this is that we would like to see the Node built-in test runner to quickly reach a feature set comparable that of external libraries such as tap or jest.

A few things to note here. First, the test runner exists inside of a larger project, so we have to be selective about what we add. For example, you will certainly get pushback from other collaborators if you try to add 20 new CLI flags just for the test runner. Also, from the beginning, the idea was to keep the test runner lean and fast. I would say that trying to build something like jest specifically is a non-goal.

[simoneb]

Thanks for the clarifications. Ok sounds good, we'll keep contributing in this area of the codebase and if at some point we see the need of a more structured approach, we may come up with a proposal for a roadmap.

Just to be clear, I wasn't suggesting that Node.js should have a test runner similar to Jest, which I agree is out of scope, nevertheless I think the current shape of the test runner could use more work before it can be used as an alternative to one of the popular third parties, and we're happy to keep contributing to improve it.

[GeoffreyBooth]

Also, when editing files in other subsystems, please make sure to tag those teams. (And in general, if the test runner requires changes to unrelated parts of Node, that’s probably something that warrants discussion.)