-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Testing: Fail E2E when page displays warning notices #13452
Conversation
Idea: Navigation needs to be abstracted, where the validation occurs as a pre-condition for the navigation promise being resolved. For example, this could be incorporated into |
I opened #14371 where I want to provide an option to override site constants through env variables. |
ee92968
to
c22e3b7
Compare
I rebased to account for #14371, also introducing a revised approach which (per #13452 (comment)) checks for errors in the markup as part of I haven't actually tested this yet, but pushing up what I have as I wrap up my day. It seems it should work fine; I'll test on Monday. |
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 still needs npm run docs:build
:)
* | ||
* @type RegExp | ||
*/ | ||
const REGEXP_PHP_ERROR = /<b>(Fatal error|Recoverable fatal error|Warning|Parse error|Notice|Strict Standards|Deprecated|Unknown error)<\/b>/; |
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.
Should this match be more detailed? <b>Notice</b>
or <b>Warning</b>
might be too common and cause false positives. We could at least add :
after closing tag:
https://github.com/php/php-src/blob/598175e/main/main.c#L1321
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.
Yeah, I suppose it risks false positives in its current form. With the placeholder formatting and multiple variants, it's harder to get a good pattern to cover all the error outputs. I agree the colon :
and even the subsequent double-space
could be a good improvement to eliminate those false positives. I'll make the change.
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.
Thank you, I will give it a spin as code wise it look good 👍
I don't know why but this is how notices and warnings are printed in my local copy of Docker for Gutenberg: Notice: Undefined property: WP_Block_Type_Registry::$x in /var/www/html/wp-content/plugins/gutenberg/lib/blocks.php on line 47
Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/gutenberg/lib/blocks.php:47) in /var/www/html/wp-admin/includes/misc.php on line 1198
<!DOCTYPE html>
``` |
b524517
to
6bdd7aa
Compare
@gziolo Hmm, by the code of https://github.com/php/php-src/blob/598175e/main/main.c#L1331 I suppose one option is to make the Another option which comes to mind is to direct the PHP errors to write to a log file, and consider a build as successful only if the log file doesn't exist / is empty. Not sure off-hand how easy this would be to implement. |
https://www.php.net/manual/en/errorfunc.configuration.php#ini.html-errors Perhaps we could normalize this behavior to ensure HTML output. A matter of calling |
Given that you can use any website to run e2e tests, I don't think that using log file would work as you might not have access to read from the filesystem in the place where such log file is stored. This makes me wonder whether we should put it behind the flag and optimize against Travis and don't care too much about all other use cases? |
Should we just land this? it seems still relevant? |
It is relevant, and still useful. Based on earlier conversation, I think there were some challenges around particular configuration setups. We could maybe ship a semi-functional implementation and improve it later. If I recall correctly, it was at least capturing issues in Travis. |
This works for me, I'd be curious to know if the tests still pass after a rebase and we can ship |
6bdd7aa
to
8d9aff1
Compare
Rebased to bring this back up to date. A few changes:
|
Size Change: 0 B Total Size: 889 kB ℹ️ View Unchanged
|
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.
LGTM 👍
I ran through a final round of testing to see how it worked. It did work correctly, but the error output isn't especially helpful:
It's also not entirely clear how to customize this messaging from within Jest (see jestjs/jest#3293). I think it can probably be done by either throwing a custom error, or by using Node's internal I'll plan to put this together in the morning. |
Return error message so it can be used in failure output
8d9aff1
to
228aad3
Compare
Updated in 965900a and 228aad3. New messaging example:
|
Extracted from: #13446
This pull request seeks to add new functionality to the end-to-end tests to fail immediately fail the tests if a page loads with warning notices present.
In Progress: Currently, the build fails, likely due to a race condition between page navigations and the
page.evaluate
result. See #13446 (comment) .Testing instructions:
Ensure end-to-end tests pass: