4 ms·

It's a bit context dependent. Generally prefer tools that allow running multiple tests in parallel because I hate waiting. Unfortunately I'm a few years out of

It's a bit context dependent. Generally prefer tools that allow running multiple tests in parallel because I hate waiting. Unfortunately I'm a few years out of date on JavaScript testing frameworks so I'll abstain from naming specific tools. If it's easy to switch between test frameworks and there's no big differentiating features I would try em all out and use whichever runs fastest. I think Test Anything Protocol [0] [1] is neat. Anything that takes inspiration from TAP is probably gonna be mostly structurally similar anyway. It's easier to point out things I dislike in a testing framework. In general, anything that gets too fancy or magical, or assertion frameworks with lots of object chaining to read like natural language. [0] https://en.wikipedia.org/wiki/Test_Anything_Protocol https://en.wikipedia.org/wiki/Test_Anything_Protocol [1] https://testanything.org/ https://testanything.org/

Tade0 3y ago
You might want to give ava a spin: https://github.com/avajs/ava/ https://github.com/avajs/ava/ It has a TAP reporter, but more importantly, as opposed to the more popular solutions, like Jest, the way it achieves parallelism is explained in the docs and won't change anytime soon, thus preventing wonky, hard to debug errors which occur when this part is abstracted away.
- eyelidlessness 3y ago
  The problem with ava (which is great! But it does have problems) is that its concurrency story is deeply tightly coupled to internals you can’t get at, and it misreports timings pretty significantly as a result. It might report single digit millisecond test runs but take about a second to run a full suite anyway, because its concurrency solution has a ton of (unreported) overhead.
  - Tade0 3y ago
    I'll take that any day over Jest's "we won't tell you how we do parallelism because no" and errors which don't reproduce with --runInBand that plagued just about every project I've been to using this framework. Perhaps it's an Angular thing - I don't understand why people keep pushing this combination.
chriswarbo 3y ago
I like the idea of TAP, but one annoyance I found is that most tooling expects the total number of tests to be output up-front, so we can't just "run everything", e.g. looping through all shell scripts in a test/ folder, or just writing a dumb, top-to-bottom script that outputs pass/fail messages. Even though it's small, the extra structure and effort needed to count tests up-front is basically the same as switching to a "proper" test framework (most of which don't output TAP :( )

Tade0 3y ago

You might want to give ava a spin: https://github.com/avajs/ava/ https://github.com/avajs/ava/ It has a TAP reporter, but more importantly, as opposed to the more popular solutions, like Jest, the way it achieves parallelism is explained in the docs and won't change anytime soon, thus preventing wonky, hard to debug errors which occur when this part is abstracted away.

eyelidlessness 3y ago
The problem with ava (which is great! But it does have problems) is that its concurrency story is deeply tightly coupled to internals you can’t get at, and it misreports timings pretty significantly as a result. It might report single digit millisecond test runs but take about a second to run a full suite anyway, because its concurrency solution has a ton of (unreported) overhead.
- Tade0 3y ago
  I'll take that any day over Jest's "we won't tell you how we do parallelism because no" and errors which don't reproduce with --runInBand that plagued just about every project I've been to using this framework. Perhaps it's an Angular thing - I don't understand why people keep pushing this combination.

chriswarbo 3y ago

I like the idea of TAP, but one annoyance I found is that most tooling expects the total number of tests to be output up-front, so we can't just "run everything", e.g. looping through all shell scripts in a test/ folder, or just writing a dumb, top-to-bottom script that outputs pass/fail messages. Even though it's small, the extra structure and effort needed to count tests up-front is basically the same as switching to a "proper" test framework (most of which don't output TAP :( )