[Feature] Allow usage of custom Mocha initializer

• I’d be willing to implement this feature

User Story

It’s a pretty big barrier to entry for testing to get a good environment set up for Electron projects. It would be great to be able to run electron-mocha instead of mocha for Electron apps that are built using Webpack (specifically electron-webpack).

Proposed Solution

Add a flag such as --electron to run electron-mocha wherever vanilla mocha would otherwise be used. This has been discussed over here: https://github.com/jprichardson/electron-mocha/issues/102

Drawbacks

• It’s another dependency to keep up with (though it could probably be labeled as a peer dependency since not all users would need it)
• electron-mocha includes a few flags that are not standard. These would need to be handed off to it somehow. Flags not used by regular mocha should quickly throw an error if a user tries to include them without --electron (this would probably provide some extra motivation for https://github.com/sysgears/mochapack/issues/34 to be tackled)
• If devs are not building with electron-webpack their project structure might deviate from what’s expected. This means there would have to be a way to inform electron-mocha of what files to consider renderer vs. main

Alternatives

Currently have a POC project electron-playground which involves maintaining separate scripts for testing:

• Code that has to be run through Webpack before testing (such as .vue files)
• Code that relies on electron and runs in the main process
• Code that relies on electron and runs in the renderer process.
• e2e tests

The tests that require electron are named .e.spec.ts and those that require webpacking are named w.spec.ts to ensure the test runner does not try and run something it can’t handle per specific script.

This is cumbersome. electron-mocha does involve spinning up a process for main and renderer tests separately, but this could probably be handled gracefully by mochapack. That would condense all 3 unit test scripts here into one. Basically instead of running one instance of mocha, it would spin up two concurrently but relying on the same bundled code.

e2e tests can and should be handled separately, so handling those in a separate script is not an issue.

[Jack-Barry]

Probably won’t be able to get around to this for a while, but some notes after completing #63 :

This will be pretty straightforward. To simplify it, I’m only going to add a flag for --byom to point to a Mocha constructor function/factory. That function can do the work of determining any settings specific to itself, rather than having to keep track of more CLI options in mochapack. If mochapack picks up a value for byom then it just uses that module to initiate an instance of Mocha in the initMocha method or somewhere around that.

[Jack-Barry]

Finally caught up on things, jumping back on this throughout the rest of the month 🔨