Could you provide an example of how/when this affects output?

I'm just having trouble seeing differences between the tests of this and the master branch; a screenshot would be great. :)

Thanks!

@namuol sure thing! It just adds more breathing room to results.

I'd rather not output the name of every successful test (i.e. should be equal), since I almost never want to read those unless there's a specific test failing, and I never actually use meaningful test names for individual tests; I just use them for describing groups of tests (i.e. the JSON output of the response should match the input).

The checkmarks keep the output "active" while tests are going on.

I agree this looks better for the trivial case from the test script, but in practice all that extra indentation is bound to increase the likelihood of word-wrapping.

What's the most important change from this PR, as far as your team is concerned?

What's the most important change from this PR, as far as your team is concerned?

Well we explicitly name each assertion i.e. t.equal(servers.length, 5, 'ensure the server list length is correct'); so it is very helpful to see each assertion output, but sounds like that should be a configurable thing since not everyone uses assertion naming. Want me to give a step at adding a CLI arg to enable this verbose mode?

Nah, it's generally a good practice to name your asserts. I'd rather this remain an "opinionated" output formatter to keep maintenance simple. Otherwise, everyone will want their own options...

I'll merge your changes in; the more I think about it, the more it makes sense to show that stuff.

@namuol OK, I added a --verbose flag. Here is the output:

Without --verbose

With --verbose

@namuol thanks! I did just push up a commit to add the --verbose flag, if you want to see it come in as a --progress flag instead to allow for minimal output I'm happy to re-work.

@namuol nowells@fc245f9 is the commit that as the current --verbose flag the produces the above output.

The line-numbers were a nice touch.

But really, I'd just like it to remain opinionated.

That is to say, the fewer CLI options, the better. I'm thinking it should be verbose for errors, and otherwise just show the names of every successful test. Essentially what --verbose already does...

Seeing as you're probably more invested in this package than I am at the moment, would you mind if I made you a collaborator on the project so you can commit/npm publish at will?

@namuol awesome! Thanks! That would be wonderful. I am nowell@strite.org on npm.

Done! I'll add you to NPM as well so you can do npm publish whenever you version-bump.

🍻

Also, I'll add you to tap-parser-yaml since these two were sorta forked in tandem.

@namuol awesome. Are you going to take care of version bumping and publishing this particular change? Or want this to my first publish to this package?

@namuol looks like you already did it. Thanks! We will be integrating this into our test chain, so I will definitely start working on any bugs that we find. Thanks again for a great library!

Yup, I took care of version bumps for both libs tonight, but for any future changes that you integrate into your workflow, feel free to do the bumps on github and NPM. Just stick to the basic rules of semantic versioning and all that jazz. 👍