This branch updates our unit tests that rely upon CDO Blockly to use mainline instead.

Blockly Setup Changes

The changes here directly mirror how we set up global Blockly when initializing the Google Blockly Wrapper for our labs.

• https://github.com/code-dot-org/code-dot-org/blob/mike/blockly-unit-tests/apps/src/sites/studio/pages/blockly.js
• https://github.com/code-dot-org/code-dot-org/blob/mike/blockly-unit-tests/apps/src/sites/studio/pages/googleblockly.js

Changes to Apps Code

Fallbacks for Unloaded Translations

Sometimes when blocks were being created we would hit errors because our translations hadn't loaded. By chaining these function calls and providing a safe English default we avoid the errors.

Registry Issues

In some cases, we need to prevent registering things (custom CSS, keyboard nav styles, context menu options) more than once. If the registry provided an API for checking if something already exists, I used that to create a helper for safe registration. In other cases, I created a simple variable to make sure we only registered once.

domToBlock parameter order

Between our fork and mainline, the order of parameters in domToBlock has swapped. This needed to be updated in apps/src/block_utils.js which is evidently just used in tests.

isWorkspaceReadOnly

This util was still marked as a TODO, which means it wasn't actually working. Related, one of our feedback tests assumed that this function would look at a global Blockly.readOnly rather than the specific workspace.readOnly, so it has been updated.

Block Limits

An old feature exists that makes it possible to provide feedback if students have used too many of a particular block. A map of block counts is updated with certain Blockly events. However, the tests use specific start blocks to exercise this. Since there no events in the integration tests, the block counts were never actually checked. To fix this, I separated out the main work of the change listener so that we call it directly when blocks are first loaded to the workspace.

Test Changes

SpritelabTest.js

Test relied on modifying Blockly.blockly_.mainBlockSpace and attempted to spy on internal event dispatch behavior.

I removed all references to Blockly.blockly_. I also introduced a setter on the Blockly wrapper for mainBlockSpace to allow mocking in tests.
Finally, I replaced jest.spyOn(...).mockImplementation() with a simple jest.fn() for dispatchEvent. This is simpler and doesn't require an existing method to spy on.

Bundle Issue

webpackKarma.config.js was telling webpack not to bundle the blockly package and instead use the global one (ie. the wrapper). The keyboard navigation plugin's source file do import directly from 'blockly' (while we generally use 'blockly/core', which was causing the plugin not to be able to access things it needed.

StudioAppTest.js

These tests triggered custom DOM events ('blocklyBlockSpaceChange') on mainBlockSpace.getCanvas(), which doesn't do anything in Google Blockly. The new fireChangeListener call properly triggers change listeners added via workspace.addChangeListener, which is how things are set up in StudioApp: https://github.com/code-dot-org/code-dot-org/blob/mike/blockly-unit-tests/apps/src/StudioApp.js#L1100

CdoUtilsTest.js

This test attempted to overwrite Blockly.serialization which is read-only in Google Blockly. The test wasn't actually using Blockly.serialization.workspaces.save(). It was stubbing getProjectSerialization(), which already returns the value we care about.

feedbackTests.js

Multiple asserts were being made to count blocks after they were loaded to the workspace ('counts all other blocks'). These worked because loadBlocksToWorkspace used to call Blockly.Xml.domToBlockSpace, which is additive. Now with mainline Blockly, the process is more complex. We convert the XML to JSON on a headless workspace as use the modern JSON deserialization workspace method which effectively clears the workspace before loading blocks. Since StudioApp.loadBlocks does not just add blocks any more, I removed this whole block of tests. Even without this, we are still appropriately exercising getCountableBlocks_.

jQuery Issues (multiple files)

I removed jQuery layout/visibility calls because they break under jsdom. Instead, I used native DOM APIs which behave consistently in tests.

Feedback Utils for functions

Several turtle tests were failing due to outdated logic in our FeedbackUtils. Most prominently, we were not considering blocks on the hidden procedure definitions workspace. This was fixed by using our custom getAllBlocks() util (which checks multiple workspace) instead of the similarly named workspace method that only looked at that single workspace.
Additionally, for tests for functions with parameters, we need to us the modern API to access the parameter names. On the fork, procedure definition blocks had a .parameterNames_ array. With mainline Blockly, all procedure blocks (incl. definitions and call blocks) have a method for accessing their procedure model, and in turn its parameters.

convertXmlToBlockly Karma tests

Several tests check that we are able to create embedded read-only workspaces by converting a string of Blockly XML into blocks. Recently, the Google Blockly version of this util became asynchronous, because we now need to fetch a user's preferred workspace theme before rendering blocks. This needed to be updated to return a promise and the tests needed to be updated to wait for it. Otherwise, we'd be attempting to check for embedded blocks synchronously, which would result in test failure.

Links

• Jira: https://codedotorg.atlassian.net/browse/CT-1050

Deployment strategy

Follow-up work

Continue unforking.

• Deprecate the CDO Blockly wrapper and fork-specific utils
• Stop importing code-dot-org/blockly
• Begin unwinding the Google Blockly Wrapper (which might also be due for a rename in the meantime)

Privacy

Security

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked