Structure of tests

[alexander-akait]

Flatten (doesn't grouping same test in directory)

test
|– ...
|– Errors.test.js
|– loader.test.js (Plugin.test.js)
|– x-option.test.js
|– ...

Nested (grouping same test in directory)

test
|– Errors.test.js
|– loader.test.js (Plugin.test.js)
|
|– options
||– x.test.js
||–  ...

Also i propose rename Error.test.js to validation.test.js (because real tests with errors should be handle inside loader/Plugin and per options file to better searching test file, also plugin/loader can have a lot of test on errors and it is bad contain their in one file).

[michael-ciniawsky]

Agreed on renaming Errors.test.js to validation.test.js and locate {Error|Warnings} in loader/Plugin/option.test.js (where it occurs), voting for a nested test structure as it is grouped and slightly cleaner in my point of view

[alexander-akait]

@michael-ciniawsky i am better on flatten, maybe we should ping here somebody for voting also

[michael-ciniawsky]

Yes someone should mediate here, it was obvious that this would happen :). Maybe I would be fine with

test
|– validation.test.js (Options Schema)
|– defaults.test.js (Loader/Plugin)
| // Options (just the option name (`option.test.js`))
|– include.test.js // for e.g
|– exclude.test.js // for e.g

[alexander-akait]

@michael-ciniawsky you can have src/include.js file and include option and src/include/index.js (in theory), it is why your structure is mesleading

[michael-ciniawsky]

I don't understand, please try to rephrase

[alexander-akait]

@michael-ciniawsky Theoretically structure:

src
|– index.js (Loader/Plugin)
|– include.js
|– include
|| – index.js
|| – action.js

What is structure of tests for your purpose?

My solution is put *.test.js file where original file placed in src and flat options/feature/etc tests in same directory.

test
|– validation.test.js (Options Schema)
|– defaults.test.js (Loader/Plugin)
|– include-options.test.js
|– include.test.js 
|– include
||– index.test.js
||– action.test.js 

I used this structure a lot of years for php/js/ruby projects and no problem, your structure really misleading.

[michael-ciniawsky]

Ok :) then someone needs to mediate here as I'm definitely disagreeing with matching src and test by default

[alexander-akait]

@michael-ciniawsky Try to convince me with arguments, maybe I've been mistaken for many years in this.

Very often in disputes you offer ideas, not having experience or not encountering this in large projects (one of them webpack-contrib/uglifyjs-webpack-plugin#280). Instead of solving the problem, useless chatter is created. It is really bad. Notice, I always quote arguments in favor my solution and describe why it is better (no pseudo code, no theoretically ideas, only real life examples and code with tests). I'm not saying that my decisions are always right. I just want to say that we create too much noise around simple problems. Perhaps the ability to rely on experience other developers is working in command? In the current problem, I do not see arguments in defense of your idea and why it is better. The time I spent on this discussion I could spend on writing new tests, made the product more stable.

At the time when a lot of developers left webpack/webpack-contrib i continued to work for which core developers gave me more permissions (npm/repo/organization). So I'm waiting for arguments in defense your structure, otherwise we use flat strcuture and never again spend time on this discussion. I do not want to look rude or impose my opinion, but I also do not want to waste precious time on chatter and waiting when someone decides to think about it.

[alexander-akait]

Opt for flatten tests, nested test files should be created for nested directories:

• index.js -> test/index.test.js
• nested/utils.js -> test/nested/utils.test.js