Mocha tests fail when loading goog.modules

Describe the bug

The mocha test suite fails when any .js file has been converted to goog.module.

To Reproduce

1. Check out cpcallen/blockly@65ceb5ce1e2d424528fd161cc506c8692eb98fd4, which includes the branch for #5026 plus one additional commit containing a trial migration of core/utils/object.js to use goog.module instead of goog.provides.
2. Run npm run clean && npm run test from the repository root.
3. Note that the mocha tests fail.
4. Run npm start and verify that tests/playground.js loads correctly from localhost http:// URL.

Expected behaviour

All test pass.

Actual behaviour

The mocha tests fail:

=======================================
== mocha
Starting webdriverio...
2021-07-12T19:43:54.971Z INFO devtools:puppeteer: Initiate new session using the DevTools protocol
2021-07-12T19:43:54.972Z INFO devtools: Launch Google Chrome with flags: --enable-automation --disable-popup-blocking --disable-extensions --disable-background-networking --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-sync --metrics-recording-only --disable-default-apps --mute-audio --no-first-run --no-default-browser-check --disable-hang-monitor --disable-prompt-on-repost --disable-client-side-phishing-detection --password-store=basic --use-mock-keychain --disable-component-extensions-with-background-pages --disable-breakpad --disable-dev-shm-usage --disable-ipc-flooding-protection --disable-renderer-backgrounding --force-fieldtrials=*BackgroundTracing/default/ --enable-features=NetworkService,NetworkServiceInProcess --disable-features=site-per-process,TranslateUI,BlinkGenPropertyTrees --window-position=0,0 --window-size=1200,900
2021-07-12T19:43:56.510Z INFO devtools: Connect Puppeteer with browser on port 49953
Initialized.
Loading url: file:///Users/cpcallen/src/blockly/tests/mocha/index.html
2021-07-12T19:43:57.011Z INFO devtools: COMMAND navigateTo("file:///Users/cpcallen/src/blockly/tests/mocha/index.html")
2021-07-12T19:43:57.812Z INFO devtools: RESULT null
2021-07-12T19:43:58.008Z INFO devtools: COMMAND findElement("css selector", "#failureCount")
2021-07-12T19:43:58.242Z INFO devtools: RESULT { 'element-6066-11e4-a52e-4f735466cecf': 'ELEMENT-1' }
2021-07-12T19:43:58.467Z INFO devtools: COMMAND getElementAttribute("ELEMENT-1", "tests_failed")
2021-07-12T19:43:58.724Z INFO devtools: RESULT 143
2021-07-12T19:43:58.726Z INFO devtools: COMMAND findElement("css selector", "#failureCount")
2021-07-12T19:43:58.726Z INFO devtools: RESULT { 'element-6066-11e4-a52e-4f735466cecf': 'ELEMENT-2' }
2021-07-12T19:43:58.730Z INFO devtools: COMMAND getElementAttribute("ELEMENT-2", "tests_failed")
2021-07-12T19:43:58.732Z INFO devtools: RESULT 143
============Blockly Mocha Test Summary=================
143
143 tests failed
============Blockly Mocha Test Summary=================
2021-07-12T19:43:58.733Z INFO devtools: COMMAND deleteSession()
2021-07-12T19:43:58.734Z INFO devtools: RESULT null
Mocha tests failed
FAILED: mocha

Additional context

I note that tests/mocha/run_mocha_tests_in_browser.js generates a file: URL, presumably to load the tests from. I further suspect that it consequently tries to load blockly_uncompressed.js from a file: URL as well. This is known to fail due to CORS errors when debug module loader in closure/goog/base.js tries to use XMLHttpRequest to load the module.

If this is indeed the cause of failure then the solution will be to use the http-server package to serve files to the browser running the tests. Some notes:

• Worth checking if the same mechanism that is used to start and stop Selenium (or something similar) can be used to start and stop http-server.
• It would be good to run the http server for the tests on a port other than the default 8080, so that they will not fail if the user has run npm run start and not terminated it with ^C yet.
• It will almost certainly be necessary to make a similar fix to the generators test, which similarly generates a file: URL in tests/generators/run_generators_in_browser.js. I’m actually not sure why these tests are currently passing.
• A PR to fix this issue should branch from the branch for #5026 (or from the goog_module, branch once that PR is merged), and target the goog_module branch.
• A PR to fix this could be branched from develop and target either goog_module or develop, but in the latter case it should land before merging #5019 to fork goog_module from develop.

[moniika]

The fix in https://github.com/google/blockly/pull/5035 resolves this issue. I will file a new issue to track looking into updating the webdriverio config to leverage some of the TestRunner tooling and include what I’ve found so far.

[moniika]

I’m also looking into updating the webdriverio config for mocha tests. I think it may be a better solution than adding the override flag for reading local files. We don’t currently utilize the TestRunner features of webdriverio and it may also improve the logs we get back when we run the tests through the console.