larsthorup / mocha-vite-puppeteer

Run your Mocha tests with Vite bundler and Puppeteer.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support usage of custom mocharc file

gabrielthomasjacobs opened this issue · comments

commented

If custom mocharc files are supported, it would allow for a lot more flexibility in projects. It might also remove the need to explicitly support other cli options like reporter/reporter-options, as those could just be set in the config file.

Standard mocharc files are usually one of type: js, json, jsonc, yml, yaml.
mocharc.js requires using "type" = "module" in the package.json

some resources:
mocha config file documentations
mocha cli loadOptions documentation

I did some testing inside the test.html to determine if a config could be passed via something like:
mocha.setup({ "ui": "bdd", "config":"./mocharc.json" });
but it doesn't appear passing a config or options key is allowed here.

This would be a great enhancement. The config will probably have to be split inside mocha-vite-puppeteer into two sets: one set for the mocha instance running in the browser (such as ui and timeout), and another set for mocha-vite-puppeteer itself (such as reporter and reporter options).

commented

Out of curiosity, if the reporter/reporter-options are configured via the mocharc.json and sent only to the mocha instance, would you expect the mocha instance to use it properly (e.g. create output files)?

If that's the case, would the config file need to be split so the cli knows what to output? e.g. when using reporter=dot

Well, no, that's not how it works. Check out the illustration at the bottom of the README.md: https://github.com/larsthorup/mocha-vite-puppeteer/

The mocha instance runs inside the browser and has no access to the file system or anything like that. Its only access to the outside world is via console.log() calls whose output are picked up by mocha-vite-puppeteer which can then perform any file-system related tasks on behalf of the mocha instance. This split is common to all test runners operating on real browsers. This is basically what makes this kind of tool a bit tricky to get right.

commented

Ah, I understand what you mean now. Thank you for the explanation!