-n option and fix for .only on dup test names

[jtlapp]

This PR provides the -n option described in #301 and the fix for #299 on which it depends.

[ljharb]

can you elaborate on this code block? adding production code just for tests seems very subpar.

[jtlapp]

By way of explanation, the -n option must inform the tape module of the number of the test to run. The above resolveModule() call requires that a module named tape have been installed. No module named tape has been installed when we run the test suite for tape itself. In order to be able to test the -n option within the tape module itself, it's necessary to load the module in the way that is required by the test suite. You'll find all the tests loading the tape module this way as well (not just mine). Without this line, the tape module would not be able to include tests of the -n option.

[ljharb]

It seems like we could resolve that by adding a devDep of "tape": "./"?

[jtlapp]

I don't know. That's trick NPM stuff. That might allow you to replace the mysterious var tape = require('../'); line found in each test file.

[ljharb]

That line isn't mysterious - that's how every npm package tests itself.

[jtlapp]

Oops, forgot to check for consistency with existing style.

Also, my colleague found a bug whereby indicating a test number greater than the number of tests results in all tests running. I'm thinking that I should run no tests in this case and do one of the following:

• output a message to the console (stdout, I presume)
• output a message to stderr
• output nothing

[ljharb]

I think that should error out without running any tests, yes.

What if I run a number that's explicitly skipped? I assume it would still be skipped.

[jtlapp]

I agree, it should still be skipped. I'll make some more unit tests. Thank you!

[jtlapp]

Another to-do item for me: Make sure the bracketed numbers are compatible with the TAP standard.

[jtlapp]

When I've got this done, should I close this PR and make a new one? (I'm new to git/github.)

[ljharb]

@jtlapp no, please do not. Rebase and force push and the PR will be updated.

[jtlapp]

Okay, I'll try to make sense of that. Out of curiosity, why a trailing newline?

[ljharb]

http://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

[jtlapp]

Thanks. That explains why I have a habit of ending all my text/data files in a newline, but I guess it's been a while since I've catted or munged code via command line tools.

[jtlapp]

Presently, if you use -n for a test that is being skipped, you get the same result as doing this using your current code base:

test.only("skip or only?", {skip: true}, (t) => { ... }

Which is this:

# SKIP lexically invalid domain name

1..0
# tests 0
# pass  0

# ok

The numbering shows that a test is being skipped -- numbers are skipped. I like that. It's informative.

I'm getting my -n implementation right before looking for how to hook it in.

[jtlapp]

I'm closing this. I found an easy way to extend the tap module to do the job. Thanks for your help!