switch to well-maintained, responsive test framework

[mykmelez]

https://github.com/tapjs/node-tap is a featureful and ergonomic test framework for Node, but it's been broken on Windows for many weeks because of bustage in a sub-dependency. Specifically, node-tap depends on https://github.com/istanbuljs/nyc/, which depends on https://github.com/tapjs/spawn-wrap/, which experienced bug istanbuljs/spawn-wrap#56.

That bug took many weeks to fix in spawn-wrap, even after I submitted istanbuljs/spawn-wrap#57, because that pull request was ignored for several weeks, after which @isaacs silently landed his own fix for the bug.

https://github.com/istanbuljs/nyc/ has since updated to the fixed version of spawn-wrap in istanbuljs/nyc@8768afe and released a new version with the fix. But https://github.com/tapjs/node-tap still hasn't updated to the latest version of https://github.com/istanbuljs/nyc.

I've now submitted tapjs/tapjs#394 for that update. But given how many weeks it's taken so far, and since my PR for spawn-wrap was ignored (and node-tap and spawn-wrap seem to have the same maintainer), I'm concerned that it'll take another few weeks for that to happen. And I really don't want Windows testing to be broken for multiple months because of downstream bustage.

So let's switch from https://github.com/tapjs/node-tap to another test framework that is well maintained and responsive to issues and pull requests.

@cvan You suggested earlier that you've typically used other test frameworks. Do you have any recommendations?

[erikvold]

I've heard good things about https://github.com/avajs/ava I haven't looked into it enough to recommend it yet, the feature set looks nice to me though.

[isaacs]

Sorry for the delay. I've been busier than usual at work, and focusing my hacking time on building v11 of node-tap rather than doing as much maintenance as I had previously.

Anyway, this should be fixed now?

[mykmelez]

@isaacs It is indeed, thanks for the fix!

FWIW, the delay isn't as much of an issue as the uncertainty. Not knowing when some bustage will be fixed morphs into wondering if it'll be fixed (i.e. whether the project is still maintained or has become abandonware). And not knowing when an issue has been resolved (or a PR made obsolete), because it isn't referenced by the commit that fixes it (or is otherwise closed as resolved), similarly contributes to that sense of uncertainty.

I know how scarce time is, and that maintenance isn't trivial (from my own work on this project, among others). I just wanted to note that a little communication goes a long way.

Anyway, it has in this case, and I appreciate the response, as well as your work on node-tap and its dependencies. I'll close this issue in favor of continuing to use node-tap in this project.