-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Parser: Runs all parser implementations against the same tests #11320
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect this may be shadowing the global DOM document
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.js
in 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
php
directly 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
php
is available and running.The CI environment runs
php
fine and so does a local build ifphp
is 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: