Mocha tests fail when loading goog.modules

[cpcallen]

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@65ceb5c, which includes the branch for Migrate Blockly from goog.provide to goog.module #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 Migrate Blockly from goog.provide to goog.module #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 Preparation for goog.module transition: base.js, deps.js #5019 to fork goog_module from develop.

[cpcallen]

@gonfunko: @moniika asked to work on this, but I'm sure you have useful knowledge about it too.

[cpcallen]

(I have made a few updates to the notes in "Additional context" above, but I think I'm now happy with it.)

[moniika]

By commenting out lines in the run_mocha_tests_in_browser.js so that the browser doesn't close after running mocha tests, I can confirm that there are errors that reference CORS policy which then seem to cause a "Failed to load resource" error.
Stack Traces:

base.js:1192 Access to XMLHttpRequest at 'file:///usr/local/google/home/kozbial/github/blockly/web-
moniika/core/utils/style.js' from origin 'null' has been blocked by CORS policy: Cross origin requests
are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.

base.js:1192 Access to XMLHttpRequest at 'file:///usr/local/google/home/kozbial/github/blockly/web-
moniika/core/utils/object.js' from origin 'null' has been blocked by CORS policy: Cross origin requests 
are only supported for protocol schemes: http, data, chrome, chrome-extension, chrome-untrusted, https.

These errors are trigged on L8 in 1index.html which is where blockly_uncompressed.js is loaded.

[moniika]

Thanks to @gonfunko. It looks like the mystery as to why the generator tests are passing is because of the flag --allow-file-access-from-files passed in the args list for "goog:chromeOptions" configured in the webdriverio options in tests/generators/run_generators_in_browser.

Adding this flag to tests/mocha/run_mocha_tests_in_browser.js fixes the errors encountered and makes the tests pass.

This is what the documentation says about this flag: "By default, file:// URIs cannot read other file:// URIs. This is an override for developers who need the old behavior for testing. ↪"

[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.

[moniika]

The fix in #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.