Jest was chosen as the tool for the contrib organization and rightly so imo. It's fast, snapshots are the hotness & the development experience is so far beyond any other offering it's almost embarrassing.
Both webpack & webpack-contrib have some interesting testing scenarios / requirements that make the conversion challenging while retaining all of Jest's features. The biggest ticket item within webpack-contrib is retaining Jest's incremental / async functionality while unit testing loaders & plugins through webpack without a pretest build step.
Fortunately, Jest has a solution for such problems, the mighty Preprocessor. Unfortunately, that is not as simple as it sounds or at lest it wasn't last I researched this issue a few months ago.
Requirements
Unit test all loaders & plugins in webpack-contrib through webpack
Retain all of Jest's functionality ( automatic test detection, snapshots, coverage, ect )
Engage the Jest team to build this with the Jest roadmap in mind to simplify maintainability
Coordinate with webpack in an effort to cover their needs as well with a single tool
Short Term Goals
Within the scope of webpack-contrib our highest priority is to get the webpack-defaults upgrades complete. A part of those upgrades is either a conversion of existing unit tests or their addition where none exist.
Given additional tooling to some extent will likely need to be developed to meet all the requirements listed above, the initial defaults pass should not execute unit tests through webpack with a pretest compile step. The simple fact is, refactors are few and far between & features land far more often. The initial pass of defaults should leverage Jest in all it's glory without compromise & a preprocessor can be added later to handle the through webpack portion as a feature in webpack-defaults.
The obvious risk there is the occasional got ya where a unit test passes but the functionality is broken in the context of webpack. Given the infrequency of that occurring, imo the level of risk is acceptable when weighed against the benefits of a no compromise implementation of Jest.
Engage the Jest team to get an initial opinion on the perceived issue from the experts as our collective Jest knowledge is currently limited.
Get a high level design together for the additional tooling needed to cover both webpack & webpack-contribs testing challenges.
Figure out where it's going to live along with project ownership. Assuming all of the above and the webpack roadmap, it may make sense to have contrib build it and hand off ownership to the webpack-core team should they want tighter reigns on utility that drives webpack's test suite.
Background
Jest was chosen as the tool for the contrib organization and rightly so imo. It's fast, snapshots are the hotness & the development experience is so far beyond any other offering it's almost embarrassing.
Both
webpack&webpack-contribhave some interesting testing scenarios / requirements that make the conversion challenging while retaining all of Jest's features. The biggest ticket item withinwebpack-contribis retaining Jest's incremental / async functionality while unit testing loaders & plugins through webpack without apretestbuild step.Fortunately, Jest has a solution for such problems, the mighty
Preprocessor. Unfortunately, that is not as simple as it sounds or at lest it wasn't last I researched this issue a few months ago.Requirements
webpack-contribthrough webpackwebpackin an effort to cover their needs as well with a single toolShort Term Goals
Within the scope of
webpack-contribour highest priority is to get thewebpack-defaultsupgrades complete. A part of those upgrades is either a conversion of existing unit tests or their addition where none exist.Given additional tooling to some extent will likely need to be developed to meet all the requirements listed above, the initial defaults pass
should notexecute unit tests through webpack with apretest compile step. The simple fact is, refactors are few and far between & features land far more often. The initial pass of defaults should leverage Jest in all it's glory without compromise & a preprocessor can be added later to handle thethrough webpackportion as a feature inwebpack-defaults.The obvious risk there is the occasional
got yawhere a unit test passes but the functionality is broken in the context of webpack. Given the infrequency of that occurring, imo the level of risk is acceptable when weighed against the benefits of a no compromise implementation of Jest.A good benchmark for test setups in the short term is https://github.com/webpack-contrib/css-loader/tree/new-loader/test
End Game
Currently very wip ...
webpack & webpack-contribstesting challenges.