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:
foo
✓ should works
bar
✓ should be after sub
Actual:
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?
Merging suites causes hooks to merge as well, which would lead to unpredictable behavior.
@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.
You have to redefine describe method to achieve this behaviour afaik.
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...
It's alright if those suites work independently i.e no need to merge hooks, but aggregated output should be comebined.
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.
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:
|_ 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
put everything in one file. maybe run a script to concatenate your test files then run script against that.
you could also write a custom reporter that could figure this out, but your output would necessarily get delayed until all tests were complete
This is still desired functionality
But there is a workaround at https://github.com/mochajs/mocha/issues/1792
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.
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.
Most helpful comment
It's alright if those suites work independently i.e no need to merge hooks, but aggregated output should be comebined.