The Test Team helps manage testing and triage across the WordPress ecosystem. They focus on user testing of the editing experience and WordPress dashboard, replicating and documenting bug reports, and supporting a culture of review and triage across the project.
If you’d like to help test Full Site Editing, please join the FSE Outreach Program. You can find current calls for testing for this program here and you can join the fun in #fse-outreach-experiment.
Welcome back to Week in Test, where contributors of any skill level can find a handy list of links and opportunities to start testing WordPress. Join the Test Team in #core-test for questions and thoughtful discussion.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Who? Any contributor.
Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
WP_List_Table extended class causes PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. notice.Who? All contributors (not just developers) who can set up a local testing environment.
Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
wp_after_tag_search filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. Ready for testing.wp_nav_menu last level items have .menu-item-has-children even when child menus are not displayed.And back for an encore performance:
early.Who? Any QA or PHP developer contributors who can (or are interested in learning how to) build automated PHPUnit tests.
Why? Automated tests improve the software development feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. for quality and backward compatibility.
The following tickets need PHPUnit tests built to accompany their respective patches:
add_settings_section(). Also needs patch testing.wp_insert_post() check if post type exists. Also has patch feedback.<test-triage> in #core-test .<test-scrub> in #core-test.Welcome back to Week in Test, where contributors of any skill level can find a handy list of links and opportunities to start testing WordPress. Join the Test Team in #core-test for questions and thoughtful discussion.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Contributors are who make WordPress as great as it is! Are you ready to get started?
Who? Any contributor.
Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
Who? All contributors (not just developers) who can set up a local testing environment.
Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
remove_accents to support non-NFC encoded characters.block.json files. Needs thorough testing across different environments.early.Who? Any QA or PHP developer contributors who can (or are interested in learning how to) build automated PHPUnit tests.
Why? Automated tests improve the software development feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. for quality and backward compatibility.
The following tickets need PHPUnit tests built to accompany their respective patches:
WP_Widget_Block outputs empty container if widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. has no output.get_sample_permalink() from unsetting $post->filter.array_intersect_key error when first argument is a string.<test-chat> in #core-test .<test-scrub> in #core-test.Hello again! Welcome to a new edition of Week in Test, where contributors of any skill level can find a handy list of links and opportunities to start testing WordPress. Join the Test Team in #core-test for thoughtful discussion, and occassional 🥛 & 🍪.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
🙋♀️ 🙋 Hi, Contributors! Let’s get rolling…
Who? Any contributor.
Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
next_posts_link_attributes and previous_posts_link_attributes are applying to the opposite links than the filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. names suggest.thumbnail) support.Who? All contributors (not just developers) who can set up a local testing environment.
Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
WP_HOME differs from WP_SITEURL (Bedrock and Docker).wp_list_authors() filterable.Who? Any QA or PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. developer contributors who can (or are interested in learning how to) build automated PHPUnit tests.
Why? Automated tests improve the software development feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. for quality and backward compatibility.
The following tickets need PHPUnit tests built to accompany their respective patches:
wp_filter_nohtml_kses() does not remove HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. comments.<test-chat> in #core-test .<test-scrub> in #core-test.<test-chat>/<test-triage> sessions from 13:00 to 16:00 or 17:00 UTC. Join the discussion.Props to @hellofromtonya and @boniu91 for peer review of this post.
Welcome to a new edition of Week in Test! This post features a curated list of where and how testers can get involved, regardless of skill level. You can find the Test Team in #core-test.
Did you know that contributions with the Test Team are also a fantastic way to level up your WordPress knowledge and skill? Dive in to contribute, and gain coveted props 😎 for a coming release.
Ready to pitch in? 🙋♀️ 🙋 Okay, let’s get started!
Who? Any contributor.
Why? It is helpful to show an issue exists for other users in order to move a ticket forward for patching.
The following new tickets are awaiting review, and need testers to attempt to reproduce the reported issue (aka “repro”), and then provide a reproduction test report with the results:
</3 in the description appears to cause a broken anchor tag. This needs testing with additional variations, such as embeds from other sources.Who? All contributors (not just developers) who can set up a local testing environment.
Why? It is necessary to apply proposed patches and test per the testing instructions in order to validate that a patch fixes the issue.
The following tickets have been reviewed and a patch provided, and need testers to apply the patch and manually test, then provide feedback through a patch test report:
WP_Widget_Block container when widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. has no output (use 55448.diff).Who? Any QA or PHP developer contributors who can (or are interested in learning how to) build automated PHPUnit tests.
Why? Automated tests improve the software development feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. for quality and backward compatibility.
The following tickets need PHPUnit tests built to accompany their respective patches:
wp_after_tag_search filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. Needs additional feedback for proposed unit test.redirect_canonical().<test-triage>/<test-chat> time: Join the discussion.<test-scrub> starting at 13:15 UTC.Props to @hellofromtonya for peer review of this post.
Welcome to this week’s edition of Week in Test! This post is a curated list of where you can get involved (i.e. where testers of all skill levels and expertise are needed), learning opportunities, and some reading to keep you informed.
This week focuses on helping with 5.9 new features and enhancements. Remember, feature freeze is 9 Nov.
Looking for ways to contribute? The following tickets and patches need contributors.
Who? All contributors (not just developers) who can set up a local testing environment, apply patches, and test per the testing instructions.
The following tickets need testers to manual test and provide feedback (test report):
Who? Any QA or PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. developer contributors who can (or is interested in learning how to) build automated PHPUnit tests.
The following tickets need PHPUnit tests build:
wp_list_users() template tagwp_http_validate_url to control which ports are allowed for remote requestsWho? Any contributor.
The following new tickets need testers to attempt reproducing the reported issue and then providing a test report with the results:
open_basedir warnings on classic post edit screens with TinyMCE plugins presentProps to @boniu91 for peer review.
Welcome to this week’s edition of Week in Test! This post is a curated list of where you can get involved (i.e. where testers of all skill levels and expertise are needed), learning opportunities, and some reading to keep you informed.
Looking for ways to contribute? The following tickets and patches need contributors.
Who? All contributors (not just developers) who can set up a local testing environment, apply patches, and test per the testing instructions.
The following tickets need testers to manual test and provide feedback (test report):
Who? Any QA or PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. developer contributors who can (or is interested in learning how to) build automated PHPUnit tests.
The following tickets need PHPUnit tests build:
_embed and _fields query parameters in the same querymonthnum query var is set without the year QVWho? Any contributor.
The following new tickets need testers to attempt reproducing the reported issue and then providing a test report with the results:
Props to @boniu91 for peer review.
A working session was held today to discuss big picture goals and what to accomplish during the 5.9 cycle.
Consensus reached as to where e2e tests will live within each repository:
All recent major changes to Core with user facing functionalities are top priorities to receive e2e tests as part of WordPress 5.9. These areas are:
tl;dr:
Along with the previous areas to test, the following priority would be to port some Core tests that are currently implemented in Gutenberg (e2e-test-utils package). Concerned tests are those related to the login feature.
The next step after this would be to improve the login tests to make them more performant. This includes for instance cookie based authentication across all tests in Core and Gutenberg.
These items are not necessarily part of 5.9 Goals. However, these are part of the bigger picture Test Roadmap.
tl;dr:
e2e-test-utils package (maintained by Gutenberg)All agreed Playwright for e2e tests would indeed have a lot of advantages for both Core and Gutenberg. However, consideration must be given for breaking changes and impacts for extenders using the test utils. Kai noted the utils could be made compatible with both Puppeteer and Playwright, meaning no breaking changes.
Also, a migration plan will need to be discussed on developed once the test utils are ready for Playwright. Part of this plan is to figure out how to change Gutenberg and Core as well as how to upgrade existing, not yet committed patches/PRs. The how and when is yet to be determined.
As there is still work to do to prepare for Playwright, the team agreed to continue with the roadmap to build e2e tests in Core.
Props @hellofromTonya for peer review and proofreading.
Welcome to this week’s edition of Week in Test! This post is a curated list of where you can get involved (i.e. where testers of all skill levels and expertise are needed), learning opportunities, and some reading to keep you informed.
Looking for ways to contribute? The following tickets and patches need contributors.
Who? All contributors (not just developers) who can set up a local testing environment, apply patches, and test per the testing instructions.
The following tickets need testers to manual test and provide feedback (test report):
clean_dirsize_cache()Who? Any QA or PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. developer contributors who can (or is interested in learning how to) build automated PHPUnit tests.
The following tickets need PHPUnit tests build:
clean_dirsize_cache()$post in update_post_cache()_embed and _fields query parameters in the same querymonthnum query var is set without the year QVWho? Any contributor.
The following new tickets need testers to attempt reproducing the reported issue and then providing a test report with the results:
get_header_image_tag doesn’t add srcset/sizesReproducing the reported issue is the first step in a new defect ticket’s lifecycle. Why? In order to fix a bug, first step is confirm the bug is reproducible and is due to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself (and not a third party like a plugin or theme).
Props to @boniu91 for peer review.
Howdy, good people! 👋
In the spirit of improving the E2E developer experience, I’d like to make a case for migrating CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s browser automation library to Playwright. I was asked to write this post after opening an experimental pull request, where I migrated a selected portion of specs to Playwright, making them available for running both locally and on CI. That happened some time ago, so there’s already been quite a bit of discussion going on there! Having said that, I’m going to try making the case again here, taking the feedback I’ve received so far into consideration. I also encourage you to check out the PR to see the implementation details and Playwright advantages in action.
It’s easier to write stable tests.
There are a few reasons why. Please read on to find out which ones I think are the most relevant for the project.
Playwright’s API is almost identical to Puppeteer’s, which means that the developer transition should be close to effortless. I think that’s a big factor here, as it significantly lowers the cost of this transition also from the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. side. A good thing to start with! 🤞
From the documentation:
Playwright performs a range of actionability checks on the elements before making actions to ensure these actions behave as expected. It auto-waits for all the relevant checks to pass and only then performs the requested action. (…)
I think it’s the number one reason for the stability improvement over Puppeteer. In practice, it means the following:
Most of the DOM changes happen asynchronously, so in order to avoid flaky behavior, a test usually explicitly wait for an element before performing an action on it. A good example would be the most frequently used click action, which usually looks like this when performed with Puppeteer:
const button = await page.waitForSelector( 'button' );
await button.click();With Playwright, thanks to the auto-waiting mechanism it becomes just:
await page.click( 'button' )This is thanks to the stability check, which makes sure the element has a bounding box and is not moving before the action is performed. I think this is a major advantage because it allows to fully test the application, including the CSS animations, which are an integral part of the user interface.
In my PR, as a proof of concept, I removed the code that disables CSS animations and the forced reduced motion, which slowed down the refactored tests (21 suites) by around 37 seconds. This number will grow with every test, but judging by the current data it shouldn’t be more than a few minutes in total. I’d say the trade-off would still be worth it, but this can be discussed and decided upon later.
What do you think about testing without animations? Should they be enabled if it’s possible, even for the cost of extra wait?
In general, all of the above comes down to writing less and simpler code to get the same or better results than Puppeteer. If you go to my PR, you’ll notice that there are more lines removed than added in the refactored tests!
With Playwright, the tests and test utilities are easier to write and follow, and the environment requires less customization (e.g. disabled animations) which actually makes it closer to what users are experiencing.
Are there any downsides to the auto-waiting mechanism?
There were some concerns about how this mechanism could affect the performance tests. Because it could potentially become a blocking factor for this migration, I decided to migrate Gutenberg’s performance specs to Playwright as a proof of concept and see what happens. So far, thankfully it looks like there isn’t much difference between Puppeteer and Playwright — the performance metrics are very close, which would be the desired outcome.
Do you think there could be any downsides to the auto-waiting mechanism? Please let me know in the comments!
This part has changed a bit due to some feedback received in the PR. Originally, I mentioned text selectors and layout-based selectors as the number one reason for making the tests and utilities easier to write and follow, as well as making them more resilient. While prioritizing user-facing attributes is still a good practice for most applications, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ is a bit different in this regard. Apparently, CSS classes are considered to be the API there, so they change less often than the user interface. Nevertheless, as some folks noticed advanced selectors are still a big win as they’d allow to, e.g. drop the use of cumbersome XPath selectors and more with powerful selector chaining. Currently, with Puppeteer, CSS selectors can only be used.
Learn more about Playwright’s advanced selectors from https://playwright.dev/docs/selectors.
The built-in Inspector is also a big advantage of Playwright. It’s quite intuitive and has some neat features like stepping through the script while running headfully or dynamically recording actions to a script — a really convenient way of quickly drafting the test. See the video below for a short demo of the script recorder.
Playwright offers a complete tracing solution. Trace can be recorded and stored in a zip file, which then can be viewed via the Trace Viewer GUI:
On the image above, you can see that the trace is displayed in a form of a film strip. Each frame can contain Before, Action, and After snapshots visualizing a complete action execution. On the left-hand side is a list of all the actions Playwright performed. Each of them can be inspected in more detail in the section on the right-hand side, where you can switch between the action log, location in the source code, and the network log.
I think it’s great to have that kind of functionality out of the box. It also shows how Playwright is intended to be a complete testing solution. With Puppeteer, there aren’t really any first-party tools for debugging, as far as I’m aware – The suggested way is to either slow down the tests in headful mode with DevTools open or use the Node.js Debugger when running headlessly.
Learn more about Playwright’s debugging tools from https://playwright.dev/docs/debug.
If there’s a goal to expand testing to browsers other than Chrome, it wouldn’t be an issue for Playwright as it supports all other major players: Firefox, WebKit, and Microsoft Edge. At the time of writing this, Puppeteer supports only Chrome and Chromium, and the official support of Firefox is currently experimental.
Learn more about Playwright browser support from https://playwright.dev/docs/browsers.
Playwright has a first-party test-runner, which is very similar to Jest test-runner (currently used for Puppeteer) but written from scratch. It contains a lot of end-to-end testing utils, tooling, concurrency, reporting, assertions, artifacts, etc., and extensive configuration support. Another quite nice thing to have without having to install and rely on third-party libraries!
Learn more about Playwright Test from https://playwright.dev/docs/intro.
I think it deserves a mention here, as it’s easy to navigate and really well written, in my opinion. Please take a few minutes and check it out for yourself at https://playwright.dev/docs/api/class-playwright – maybe you’ll find even more reasons to switch to Playwright? 😉
Writing good, stable E2E tests is often a struggle. If there’s a chance of improving that, especially with such a low cost, then it should be done. I would be happy to work on this task if there’s a consensus to move it forward.
Thanks for reading. I’m looking forward to all the feedback!
Props to @hellofromtonya and @boniu91 for proofreading!
Here is the agenda for the upcoming Test Team Chat scheduled for 2021-09-28 13:00.
This meeting is held in the #core-test channel in the Making WordPress slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
Do you have something to propose for the agenda? Please leave a comment below.
Can’t make the meeting? Share anything relevant for the discussion in a comment below.
Props: @boniu91 for peer review.
You must be logged in to post a comment.