Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: move test helpers from samples into core #5969

Merged
merged 24 commits into from
Mar 4, 2022

Conversation

BeksOmega
Copy link
Collaborator

The basics

  • I branched from develop
  • My pull request is against develop
  • My code follows the style guide

The details

Resolves

Closes #5466

Proposed Changes

Moves tests helpers that were in samples into core. Creates a new namespace for helpers. Splits helpers into different files to help with organization.

Behavior Before Change

Core depended on test helpers in samples, which depended on core.

Behavior After Change

Test helpers still exist in samples (for now) but core no longer depends on them.

Reason for Changes

When these were samples, we had to keep releasing dev tools when doing changes to get CI to pass. This makes it easy to change them as we change things in core, if necessary.

Test Coverage

All unit tests pass.

Documentation

N/A

Additional Information

The only issue is that the field serialization tests no longer work, because they rely on the test blocks, which do still exist in samples. But I don't think that should be blocking.

Also: this PR should be ok to review commit-by-commit (assuming I didn't mess anything up when I reorganized a few commits) if that's easier.

@BeksOmega BeksOmega requested a review from a team as a code owner March 1, 2022 22:46
@BeksOmega BeksOmega requested a review from gonfunko March 1, 2022 22:46
@@ -0,0 +1,240 @@
/**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Throughout, was the conversion to goog modules necessary? It appears these were already ES modules in dev-tools, so moving backwards seems not ideal.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, not sure. Before it seems we were just accessing these via testHelpers which was a global thing. I could try to move back to that. Or is there a better way to access ES modules from inside closure modules?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should be able to just do goog.declareModuleId() (per https://github.com/google/closure-compiler/wiki/Migrating-from-goog.modules-to-ES6-modules), and then still be able to goog.require it from Closure modules even though it's an ES module.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried, but for some reason it's "breaking" the tests. The suites are being evaluated, but the tests are not (based on console logging). You can check out my changes here.

As far as I can tell, what I did matches what you did in this commit, so I don't know what the problem could be. And I haven't been able to find anyone online having the same issue :/ Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like mochajs/mocha#2816, mocha is being run before the tests are loaded. Adding type="module" to the script tag at the bottom of index.html that calls mocha.run fixes it, and the tests pass!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you so much Aaron! I should have been able to find that -.- But I was looking for a closure related problem. Turns out closure wasn't the issue at all!

tests/mocha/index.html Outdated Show resolved Hide resolved
tests/mocha/block_test.js Outdated Show resolved Hide resolved
tests/mocha/field_registry_test.js Outdated Show resolved Hide resolved
tests/mocha/field_test.js Outdated Show resolved Hide resolved
tests/mocha/test_helpers/toolbox_definitions.js Outdated Show resolved Hide resolved
Copy link
Contributor

@gonfunko gonfunko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM once tests are updated to run properly.

@BeksOmega BeksOmega merged commit 2edd228 into google:develop Mar 4, 2022


suite('ASTNode', function() {
console.log('1/a');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this debugging that got committed by accident? (Here and several places below).

},
"rules": {
"no-unused-vars": ["off"],
// Allow uncommented helper functions in tests.
"require-jsdoc": ["off"],
"prefer-rest-params": ["off"]
"prefer-rest-params": ["off"],
"no-invalid-this": ["off"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably much better to turn this off only where it is necessary. See e.g. core/utils/global.js.

@@ -3,7 +3,7 @@
* Copyright 2020 Google LLC
* SPDX-License-Identifier: Apache-2.0
*/
goog.module('Blockly.test.procedureHelpers');
goog.declareModuleId('Blockly.test.helpers.procedures');
Copy link
Contributor

@cpcallen cpcallen Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests can't be converted to ES Modules until the test harness is modified so they are not loaded directly from file:// URLs.

This change causes an endless stream of:

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.  block_definitions.js:1
Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.  events.js:1

(etc.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The result of which is that the Mocha tests "pass" because none of them even get loaded, so there can be no failures. Zero failures === success, according to the test harness.)

Copy link
Contributor

@cpcallen cpcallen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. This one went in a little prematurely, I fear…

Comment on lines +38 to +39
* @template {TestCase} T
* @template {TestSuite} U
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I note that this is causing additional warnings during build (specifically, while doing build:deps:

WARNING in /Users/cpcallen/src/blockly/tests/mocha/test_helpers/common.js at 38, 3: Bounded generic semantics are currently still in development
WARNING in /Users/cpcallen/src/blockly/tests/mocha/test_helpers/common.js at 39, 3: Bounded generic semantics are currently still in development

(These two plus three more below).

I checked to see if there was some way to suppress these warnings, but I was not able to find one and filed google/closure-library#1156 to request such a feature.

@BeksOmega BeksOmega deleted the refact/helpers-to-core branch April 5, 2022 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants