Parser: Runs all parser implementations against the same tests#11320
Parser: Runs all parser implementations against the same tests#11320
Conversation
aduth
left a comment
There was a problem hiding this comment.
Would be good if we can be tolerant to environments where PHP is not available, though not strictly a blocker.
| } ); | ||
| } ); | ||
| describe( 'block-serialization-default-parser-js', testParser( parse ) ); | ||
| describe( 'block-serialization-default-parser-php', testParser( ( document ) => JSON.parse( |
There was a problem hiding this comment.
I expect this may be shadowing the global DOM document.
There was a problem hiding this comment.
it will be. I forgot we are avoiding that…will change
|
Tests are running all clear locally for me. Rebased against |
So far we haven't added too many tests to the parsers but the ones we _have_ added are in separate places and each implementation runs against a different set of tests. In this patch we're creating `shared-tests.js` in the spec parser that defines a suite of conformance tests for the parser and then we're using that base test-builder to dynamically create test suites for each implementation such that they all run the same suite. It's probably easier to understand by reading the code than this summary. Of note: by calling to `php` directly we're able to run the PHP parsers against the same tests as we are the JavaScript implementations. We should be able to do this for any implementation as long as the required binaries are available in the CI environment (Rust, for example).
749b9c7 to
2c1d61d
Compare
| exports[`block-serialization-spec-parser-php basic parsing parse() works properly 1`] = ` | ||
| Array [ | ||
| Object { | ||
| "attrs": Array [], |
There was a problem hiding this comment.
This is concerning that it produces different type for attrs property.
Should we add test which validates that both outputs generated by parsers are deeply equal?
There was a problem hiding this comment.
probably something to look into yes, but not here?
I don't think this patch introduced the change so much as brought it to light.
There was a problem hiding this comment.
I'm just leaving a note that it doesn't work as expected. The second parser doesn't have this issue :)
| /** | ||
| * Internal dependencies | ||
| */ | ||
| import { jsTester, phpTester } from '../../block-serialization-spec-parser/shared-tests'; |
There was a problem hiding this comment.
We should have some place to keep shared logic :)
With the current setup of repository and Lerna flow for publishing, this folder will get published to npm. It's not a big deal. However, we should figure out how to tackle it. Maybe it's okey to keep it in the spec parser package but we should import it as:
import { jsTester, phpTester } from '@wordpress/block-serialization-spec-parser/shared-tests';and include @wordpress/block-serialization-spec-parser as a dev dependency?
There was a problem hiding this comment.
I changed to use this and then moved jsTester and phpTester into index.js. this created a new problem which was the import of node modules in the code.
to work around this I hid require( 'child_process' ) behind a 'test' === process.env.NODE_ENV check
do you think this is a reasonable mechanism to keep the unwanted node code out of the runtime while preserving it in the tests?
gziolo
left a comment
There was a problem hiding this comment.
Nice, I like it. I got scared at first seeing PHP file included, but it makes perfect sense to consolidate it here to be able to share tests. Awesome idea 👍
…rnmobile/port-quote-block-step-1 * 'master' of https://github.com/WordPress/gutenberg: (22 commits) Add removed periods to block descriptions. (#11367) Remove findDOMNode usage from the inserter (#11363) Remove deprecated componentWillReceiveProps from TinyMCE component (#11368) Create file blocks when dropping multiple files at once (#11297) Try avoiding the deprecated findDOMNode API from DropZone Provider (#11168) Fix: make meta+A behaviour of selecting all blocks work on safari and firefox. (#8180) Remove _wpGutenbergCodeEditorSettings and wp.codeEditor assets (#11342) Remove the Cloudflare warning (#11350) Image Block: Use source_url for media file link (#11254) Enhance styling of nextpage block using the Hr element (#11354) Embed block refactor and tidy (#10958) Nonce Middleware: Wrap the nonce middleware function into it's own function that isn't regenerated on every API request. (#11347) Fix RTL block alignments (#11293) RichText: fix buggy enter/delete behaviour (#11287) Remove code coverage setup (#11198) Parser: Runs all parser implementations against the same tests (#11320) Stop trying to autosave when title and classic block content both are empty. (#10404) Fix "Mac OS" typo + use fancy quotes consistently (#11310) Update documentation link paths (#11324) Editor: Reshape blocks state under own key (#11315) ... # Conflicts: # gutenberg-mobile
In #11320 we started running all parsers against the same set of unit tests. Unfortunately when the PHP-based parsers failed inside the PHP process or returned non-JSON data then the tests would fail without providing any information about why. My personal workaround was to manually run the PHP test runner from the command line to see the output. This was inefficient. In this patch we're trapping the response code from the PHP test runner and throwing an `Error` with the output from `php` so that our `jest` tests can see and report them. This will make it easier debug failing tests.
In #11320 we started running all parsers against the same set of unit tests. Unfortunately when the PHP-based parsers failed inside the PHP process or returned non-JSON data then the tests would fail without providing any information about why. My personal workaround was to manually run the PHP test runner from the command line to see the output. This was inefficient. In this patch we're trapping the response code from the PHP test runner and throwing an `Error` with the output from `php` so that our `jest` tests can see and report them. This will make it easier debug failing tests.
So far we haven't added too many tests to the parsers but the ones we
have added are in separate places and each implementation runs against
a different set of tests.
In this patch we're creating
shared-tests.jsin the spec parser thatdefines a suite of conformance tests for the parser and then we're using
that base test-builder to dynamically create test suites for each
implementation such that they all run the same suite.
It's probably easier to understand by reading the code than this
summary.
Of note: by calling to
phpdirectly we're able to run the PHP parsersagainst the same tests as we are the JavaScript implementations. We
should be able to do this for any implementation as long as the required
binaries are available in the CI environment (Rust, for example).
Update Now this only runs the PHP tests if
phpis available and running.The CI environment runs
phpfine and so does a local build ifphpis installed.There's no major need to have the PHP parser tests run on every build though and
in order to not block people who are working on JS these tests will now skip in
such a case.
PHP not available

PHP available

Checklist: