Why Doesn't (JS Testing Library) AVA Have "Suites" (or Any Other Groupings)?

Question

I'm looking at the AVA test runner, and it's concurrency feature seems pretty compelling. However, I'm used to Mocha, where you can organize your tests like so:

describe('Some Class', () => {
    describe('#someMethod', () => {
        describe('some condition', () => {
            it('does something', () => {});
        });
    });
});

By organizing tests this way you can easily tell what components are affected when a bunch of tests fail, and you can easily re-run the tests for a specific class/method/condition.

But AVA doesn't have any of that. Its tests lack any "meta-information" at all and are just:

test(t => {
    t.deepEqual([1, 2], [1, 2]);
});

But obviously AVA is a popular and widely-used framework, so my question is: how does it work without test meta-information? Is there some other way of defining meta-information in AVA? Is the meta-information just not needed because of other features AVA has?

Basically, as an AVA outsider, I'm trying to understand how it works when you have a real test suite (not just the basic tests shown in the AVA examples). Or to put it another way, if I switch to AVA, will I miss the test organization that's in Mocha (and most other test runners)?

Alister

github.com/avajs/ava/issues/222 – Bernettabernette

As to whether or not you'll "miss" it, if ava-spec doesn't work for you, it's hard to say--that's kind of an opinion thing. – Bernettabernette

Thanks, that link was very helpful, although it did makes AVA seem rather half-baked. The thread is full of people agreeing that test groups are good (as well as a few "I don't need it so no one else should" posts), and yet after over a year of the issue existing nothing has happened (unless you count someone making their own library because the AVA devs won't). I think that scares me away from it more than the lack of groups! But at least now I understand why AVA lacks groups :) – Alister

It's nothing to do with being "half-baked" rather that the particular itch you have isn't shared by the maintainer. ava-spec seems to address your particular need, but parallelism may be at risk, I can't tell. – Bernettabernette

I guess to me a "fully-baked" library can address concerns expressed by its users even if they don't align with the maintainers. AVA has failed to address the suite thing for over a year, and similarly has failed to address running JSX files for almost as long. As library maintainers it's completely their prerogative to do that, but to me a library that fails to address issues in a timely fashion unless they come from the maintainers is "half-baked". – Alister

Fork, extend, PR! – Bernettabernette

Answer 1

Having used Ava for a bit now it appears that the answer to my question is that Ava does have suites, but unlike in Mocha (or similar frameworks) which explicitly define suites, the suites in Ava are implicit, and are based on the file containing the test.

In other words, if you want to run certain code beforeEach test in a given "suite", you simply put those tests in the same file as the test.beforeEach statement, and then it will only run before those tests.

Obviously this results in less granular test output, as you can't nest describe statements the way you can in Mocha. However, when Ava shows test output it uses the file structure to help alleviate this.

For instance, a test "can login" in a file `services/facebook' would result in the following output:

services › facebook › can login

Alister

Answer 2

If you want, there is a module ava-spec that tries to reintroduce this to ava.

Valentia