Ava: Recipe for moving from Mocha

[sindresorhus]

Most people already use Mocha and will need some guidance on how AVA is different and how to achieve the same thing with it. We should have a recipe for this.

Any Mocha converts interested in helping out with this?

[ghost]

Thanks so much for reaching out on Twitter and opening this issue! This type of outreach is great to see and feels very welcoming :grin:

@sindresorhus asked me to elaborate on my usage of Mocha:

I make heavy use of Mocha's describe keyword (and context, which is an alias for describe). I find it helps me organize large test files into more manageable logical chunks (Example). I'm currently attempting to migrate nodecg/nodecg's tests from Mocha to AVA, but I'm not sure how to do so in an organized manner. For instance, looking at AVA's 619-line test/api.js, I'm unsure if having such a large file is a best practice or not. To me, a file of that length feels overwhelming and hard to maintain.

Does it make sense to split an API's tests up by method, one test file for each method? Or is the added overhead of having to maintain that many files more of a burden than maintaining a single file of much greater length? If using a single file to test a large API, what is the best way to keep that file organized and easy to come back to?

Having described my issue, I think what I may need more than an explicit Mocha recipe is a set of best practices for AVA.

Thanks again for the outreach and for AVA!

[philmill]

I'm also coming from frameworks which use describe and context for organization. I'm wondering if something like Tape's t.test would suffice although contexts aren't tests.

I tried nesting a failing test within an empty test which just passes as an organizational experiment.

test('parent', (t) => {
  test('child', (tc) => {
    tc.fail();
  });
});

The lack of contexts is certainly not a deal breaker as the features presented with AVA are compelling enough for me to switch. But in regards to writing a recipe for Mocha converts, it might be difficult with the current API. Arguably if AVA forces me to write smaller test files which represent more narrowly focused context, that's probably a good thing.

[ghost]

@philmill: Does that still happen if you do something like

test('parent', (t) => {
  test('child', (tc) => {
    tc.fail();
    t.end();
  });
});

?

[philmill]

Hey thanks for the suggestion @talexand, but the test still passes (results in infinite loop in call back mode). Also requiring calls to end() in callback mode isn't ideal.

To be clear, I'm not really suggesting this as a solution to organization. It's just the first thing I tried after looking over the available API and searching for others who have tried similar contextual organization in AVA. I'm thinking this isn't how tests are intended to be structured and possibly not on the road map either (which is fine).

[sindresorhus]

Nested Unit Tests: An Anti-Pattern - https://twitter.com/kentcdodds/status/735502601119137793

// @kentcdodds

[jamestalmage]

Nice! We should create an "Avoid beforeEach" recipe and link to that video!