[WIP] Add a basic test for shortcode transformation

[danielbachhuber]

The beginnings of the solution to #7030, #4456, etc.

[danielbachhuber]

The significant underlying challenge, as documented in the diff, with adding tests around segmentHTMLToShortcodeBlock is its dependency on functions which are in-turn dependent on getBlockTypes() and getBlockType(). Both of the aforementioned functions are dependent on select( 'core/blocks' ), which ultimately exposes the fact that all block types are defined at runtime.

On a related note, it's annoying to need to redefine all of the block types in the test. I suspect this will be very brittle and break as soon as any block type definition changes. Related #6512

As a dirty hack to get things started, I've injected blockTypes into each of the functions that need theme. What's a better approach we could take? Is there some pattern for overloading select( 'core/blocks' )?

[danielbachhuber]

uuid being a random value is the cause of the test failure right now. What's the best way of addressing?

[aduth]

Not entirely sure it works in this specific usage, but perhaps expect.any( String ) ?

http://jestjs.io/docs/en/expect#expectanyconstructor

[danielbachhuber]

Not entirely sure it works in this specific usage

Yeah, I suppose I could make the assertions a bit more verbose and inspect each part of the array.

Another idea is to create a wrapper for the uuid function that lets us inject some state for the purposes of testing.

[gziolo]

expect.any( String ) is better, we don't care about what uuid produces in this context.

[aduth]

Related: #336

[aduth]

Noting that getBlockType is O(1) (object lookup by property) and this is O(n)

[danielbachhuber]

@WordPress/gutenberg-core Suggestions on how to move forward with this? My preference is to not modify createBlock and getBlockTransforms, but I don't have a good idea on how to solve the broader global state problem.

I'll need to resolve this PR in order to move forward with #7030, #4456 and others.

[noisysocks]

Could we call registerCoreBlocks() in the test? It looks like this is what we do to test BlockSwitcher in editor/components/block-switcher/test/index.js.

[gziolo]

Could we call registerCoreBlocks() in the test? It looks like this is what we do to test BlockSwitcher in editor/components/block-switcher/test/index.js.

Assuming you want to use existing blocks, that would be the easiest way to go. Otherwise, you can also mock getBlockTypes to return whatever you need.

[danielbachhuber]

Could we call registerCoreBlocks() in the test? It looks like this is what we do to test BlockSwitcher in editor/components/block-switcher/test/index.js.

🎉 That worked way better than I expected. Thanks @noisysocks !

Closing in favor of #7823