Group up descriptions with same names

[qfox]

Why mocha doesn't grouping them?

File1 about some.foo:

describe('some', function () {
  describe('foo', function () {
    it('should works', function () { });
  });
});

File2 about some.bar:

describe('some', function () {
  describe('foo', function () {
    it('should be after sub', function () { });
  });
});

Expected:

  some
    foo
      ✓ should works
    bar
      ✓ should be after sub

Actual:

  some
    foo
      ✓ should works

  some
    bar
      ✓ should be after sub

Can I force mocha somehow to group them up? Why it forces me to write one big file with all these specs?

[boneskull]

Merging suites causes hooks to merge as well, which would lead to unpredictable behavior.

[pronebird]

@boneskull is it possible to automatically group them by folder structure?

i.e. if I have tests for reducers under reducers/*, I'd like everything to be under reducers.

[qfox]

You have to redefine describe method to achieve this behaviour afaik.

[widget-]

Merging suites causes hooks to merge as well, which would lead to unpredictable behavior.

I was actually expecting that hooks would merge like that, so that I can do per-test setup and teardown without having to include and execute each hook in each test file.

Of course now that everyone's had to write hacks around it anyway...

[pronebird]

It's alright if those suites work independently i.e no need to merge hooks, but aggregated output should be comebined.

[ScottFreeCode]

Merging suites causes hooks to merge as well, which would lead to unpredictable behavior.

I was actually expecting that hooks would merge like that, so that I can do per-test setup and teardown without having to include and execute each hook in each test file.

Just in case it's not clear, if you need them for literally every test, you can just make the hooks global (i.e. call them once outside of any describe/context/suite). It's when you need them for suites in a lot of different test files, but not in all, that this technique would be necessary instead.

[MarkoCen]

I know this issue closed for a while, but can someone provide a walk around? Currently we use Mocha to test React components, the folder structure looks like:

components
  |_ Foo
  |   |_ Foo.jsx
  |   |_ Foo.spec.js
  |_ Bar
      |_ Bar.jsx
      |_ Bar.spec.js

And in each test file, the describe structure looks like:

// Foo.spec.js
describe('components', () => {
    describe('<Foo />', () => {
        it('...')
    })
})

// Bar.spec.js
describe('components', () => {
    describe('<Bar />', () => {
        it('...')
    })
})

We are expecting the output in a hierarchical structure which make more sense to us

components
    <Foo />
        ✓ should works
    <Bar />
        ✓ should works

[boneskull]

put everything in one file. maybe run a script to concatenate your test files then run script against that.

[boneskull]

you could also write a custom reporter that could figure this out, but your output would necessarily get delayed until all tests were complete

[paulbhartzog]

This is still desired functionality

But there is a workaround at #1792

[baarney]

Instead of adding the suites to the files and merging them, would it be possible to use a .mocharc.json local to sub directories to define a new suite for each sub dir?

Something like:

|_ components
|   |_ .mocharc.json
|   |_ Foo
|   |   |_ Foo.jsx
|   |   |_ Foo.spec.js
|   |_ Bar
|       |_ Bar.jsx
|       |_ Bar.spec.js
|_ integration
    |_ .mocharc.json
    |_ Foo
        |_ Foo.jsx
        |_ Foo.spec.js

Where the individual files just contained their own suites:

// Foo.spec.js
describe('<Foo />', () => {
    it('...')
})

// Bar.spec.js
describe('<Bar />', () => {
    it('...')
})

And the local mocha files defined new suites:

// components/.mocharc.json
{
    "describe": "components"
}

// integration/.mocharc.json
{
    "describe": "integration"
}

This wouldn't cover every case of grouping suites, but it would cover the common case of 1 suite per directory.

Some crossover with #3781 - support granular configuration.

[djaqua]

Instead of adding the suites to the files and merging them, would it be possible to use a .mocharc.json local to sub directories to define a new suite for each sub dir?

Take my input with a grain of salt -- I am new at NodeJS testing frameworks, but I strongly suspect this approach would be subject to the same concern that boneskull pointed out ("your output would necessarily get delayed until all tests were complete") but I must admit this would be the most eloquent and DRY usage scenario.

[danon]

Instead of adding the suites to the files and merging them, would it be possible to use a .mocharc.json local to sub directories to define a new suite for each sub dir?

Take my input with a grain of salt -- I am new at NodeJS testing frameworks, but I strongly suspect this approach would be subject to the same concern that boneskull pointed out ("your output would necessarily get delayed until all tests were complete") but I must admit this would be the most eloquent and DRY usage scenario.

I can imagine it's possible to code it up in such a way, that the runner would first discover all the suites in all of the files, and then run the tests later (like currently it discovers dynamic tests).

[AshotN]

@JoshuaKGoldberg would you have a different interpretation on this now that you are maintaining Mocha?

[JoshuaKGoldberg]

Maybe 😄. No promises. This doesn't strike me as a very important thing for us to approach. For anybody who hasn't read #5027, context: we're not looking to shake things up. That includes not changing Mocha's default reporters or hooks any time soon. So even if this were to be accepted it wouldn't be very high priority.

Also, per #1413 (comment), this actually does have deeper implications in Mocha than it seems at first glance. So re-triaging this issue -let alone a technical proposal- is blocked on us in the maintenance team deeply understanding Mocha's hooks.