Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Test runner

See original GitHub issue

tap is a bit of a bear.

It’s slowing me down, though I’m not sure by how much.

Mostly tap is unfamiliar; though an unfamiliar test runner is a still a hurdle to contribution.

Some things it does well, like making sure a certain number of assertions are called or holding up a test until two things have each finished. Though those could be accomplished with Promise.all and an async test with an assertion on sinon.stub().

Some of the things I find odd:

The requirement for t.end().
That it doesn’t print a full stack trace on an exception.
When things go wrong in some async code, the test just hangs. (Though maybe that would be fixed by an unhandled promise rejection handler?)
Sometimes tests hang when everything seems to be fine, on account of the runner – because I’ve miscounted t.plan or not put the t.end in the right place. IIRC this is something @jlilja and @RichardLitt were running into as well.

There are a chunk of data-driven tests in the codebase (maybe mostly in test_common.js?) In other projects I’ve taken to writing tests like those using Sazerac. It makes them much easier to read and write and easy to read when they fail. Unfortunately it doesn’t support tap.

If we decided to migrate, I imagine we’d need to mix two runners for a while. That seems like a bit of a drag. Though tap is so unopinionated, I imagine there is a way to make it coexist with another runner.

I’m most familiar with Mocha, and especially like the way it handles async. Had a couple bad run-ins with Jest recently (metabolize/apollo-resolver-gcs#4), though I’m game to give it another try, especially if someone wants to champion it.

Could also wait this out – to see if Jest fixes these issues or if we get used to tap.