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)?
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