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.
Please drop by any time in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. with questions or to help out.
Testing for backend upgrades, refactors of code, and overall any new feature that cannot be “touched or seen” regularly feels very challenging for most WordPress developers.
Sometimes unit-testing can do part of the heavy lifting, especially when having expertise in TDD, as a great deliverable could be provided.
The problem with unit-tests is that sometimes they are completely biased to our thoughts and ideas. It’s extremely difficult to think outside the box (especially when you are absorbed into a development that takes most of our attention), and this could potentially leave behind some scenarios you have not considered testing.
Adding up, when finally code is delivered, including sometimes those unit-tests, the rest of the people who are going to review it will not have the full understanding of the problem, with all the nuances, edge cases, or scenarios that could pop out of your resulting code.
As a WordPress developer, you have to consider that other reviewers in the team could range from a coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. committer with 15 years of code to a brand-new testing contributor out of a WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. willing to start lending a hand. And getting them to review if the unit tests are right, or even to review the code and add new unit-tests for more edge cases is, in numerous instances, even for the most experienced reviewers, a hard task and something to avoid.
Here is why a Testing Use-Case could become really handy for these scenarios, a paradigm of testing that could be easily learned and applied and would help further progress many reports with patches that have been stuck for ages.
Let’s dive into the Testing Use-Case
Ideally, from a Testing perspective, the best code refactor, patch, upgrade, or feature is the one that actually addresses a problem you are already having.
For example, as a patch creator, you can find any of these scenarios:
Have a theme or a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that is missing this functionality.
Find a deprecation notice in the logs.
Find an error in code that requires not only a quick fix but a whole revamp of the code.
Have a real-life requirement by any real stakeholder in our business or life in general, and we can express the entire demand down to the last detail.
These are all examples of Testing-Use Cases
But what happens if you don’t have any of those? What if you are a code freestyler that likes to sort things before they actually happen? Or maybe you have been developing somewhere else and out of sudden you think about an alternative fix that could be improved, despite not really having a real-life example to showcase our idea?
Here is where building a Testing Use-Case becomes handy.
Ideas to Build Your Testing Use-Case
Not it’s time to put some examples of the most common issues that were found lately and how implementing a Testing Use-Cases could help to move forward the patch and overall any report that could potentially get stuck.
The Hook
One of the most common reports with troubles to be tested, and many end up in the “pending box” because of new HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.. Most hooks come out of a specific need from a dev, but for some reason, many devs fear that explaining their use-case could feel “agendistic” and not usable by the majority. Also, it’s very common that there is almost always a workaround using outlandish PHPPHPPHP (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. https://www.php.net/manual/en/preface.php. functions that bypass many standards and are not ideal by any means to achieve the same result as what a hook could provide us. So it’s very common that Hooks fade into oblivion.
Ideally, the #1 Testing Use-Case is, by far, explaining your business scenario without fearing any critique. Say you have a client that is paying you a big ticket, and you need that damned hook to get that attribute to do that selective filtering for the membership plugin you are building. This is totally fine if you need this hook for a commercial case. You can think that your case is unique and explanation will reveal it, but if you feel the need for this hook and there is no other straightforward way to achieve the same result without workarounds and hacks, it should be enough. Explaining the alternative solutions that were investigated will support your case. You may think that adding a hook to code is a simple thing, but when it is added, there will be no way to remove it or make changes that will break backwards compatibility, so the hook should be in the right place when it is definitely needed and have the right name and parameters. In addition, it should be documented in the code and in the Field guide and other documentation later. That one line of code requires a lot of support to happen.
Now to create the Testing Use-Case we have two options:
You can actually provide some of the code of that plugin you are building that showcases the feature where the new hook you are willing to implement is going to be applied.
If you would rather not showcase your code for copyright dilemmas with your client (funny in a GPLGPLGPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. environment, but we all know that this still happens), reproduce a minimal MVPMinimum Viable Product"A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development." - WikiPedia version of what you are willing to achieve, mocking some data or building a hydration function to fill whatever content is required to display the issue, and creating a very simple plugin that delivers that and uses that hook and executes successfully.
Choose whatever you prefer. But be aware that what is actually problematic is making your way through it without explaining much, without any testing at all, and despite the hook being super simple, straightforward, and unlikely to be problematic at all, this always leads to distrust and leans towards the forgotten zone where it will never be reviewed and integrated into the core. It’s always better to be transparent and clear of what needs to be done in a GPL environment, and in the worst case, discuss the feasibility and maybe a better clean code alternative if possible.
There is a rule in the WordPress community: never refactor if you don’t have a good reason for this. This is mainly because it takes many resources to test and debug issues coming from the refactor, and most code reviewers are busy enough just with the regular bugs to be fixed and pending improvements to be implemented to invest time in this protocol, so refactoring could be important but not as critical as other topics.
But very occasionally, there could a good reason for a code refactor, for example, an upcoming PHP deprecation.
In these cases, the best scenario, unfortunately, is waiting for the deprecation notice reports to appear, and start fixing from there, one by one. Bear in mind that deprecations take ages to be converted into unsupported features; hence, waiting is probably the best and easiest bet.
But what if you are a restless soul and like to have everything bleeding edge updated?
The following steps are recommended after the patch has been built (or before):
First, identify which core functions you have modified. If there are unit-tests already, you can edit them to cover your new code; otherwise you could always build them later.
Consider that the current function was working as-is with the current premise. You should start building a very simple plugin that uses this old premise with all the functions you modified, test them, and display the results.
After that, you will think about your new premise and again, in the same plugin, apply it once more to all the functions you modified.
Remember that both, before and after, you should be passing the test with the new premises. Yes, with a unit-test you are doing this. But, as it was commented in the beginning, unit-tests can become very convoluted (because they are not generally designed for simplicity, but for heavy-lifting the future-proof of the whole system). On the other side, a plugin can be elegant, simple, and easy to showcase all we want to test. Any coder, regardless of his coding level, will probably be able to inspect it, understand it, and maybe think in more edge cases based on what he sees. It’s a new paradigm of simplicity and support for your peer reviewers. And perhaps the difference between a lost into oblivion patch or a patch that will be reviewed comfortably and steadily. As a rule of thumb, it’s easier to port a test use-case plugin to unit-tests than the other way around.
This categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. is like a hodgepodge because here you could find very different examples, and it’s going to be very difficult to make a general assumption on how to always proceed. But some rule of thumb could apply here, similar to the two previous sections:
If you have a real use case, a feature required by your client, or a snippet of code that can prove your enhancement, this will be sufficient. You simply need something more than unit-tests, that again, can be biased. Something that can be replicated in the WP front-end or admin panel and be tested with real data, not just with the mock samples from the unit-testing framework. Finding any of these is going to be the ideal scenario for most cases.
If, for some reason in life, it happens that you have come to this enhancement almost out of nowhere, while reviewing some other thing or for whatever other reason, a plugin that proves the new feature is clearly needed. The steps are very similar to the previous section, “Code Refactors” but adapting to the potential new functions we have developed.
Finally, the crown’s jewel of backend patches. In fact, most devs in the performance team are relatively familiar with this; hence, not much to be explained here for them. But just some general ideas for those who are still not very familiar with this.
A performance upgrade must factually test that there is a performance upgrade. It’s not enough with “before this it took 2 seconds and not it takes 1.” Real data that could be deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. in multiple computers, environments, etc. is required, and really show that there is a real performance improvement.
For this, you will need to write a plugin that does, at minimal, these two things:
A hydration system to generate X number of whatever we need to test. If a WP_Query with 10K posts should be tested, then a hydration plugin that actually creates those 10K dummy posts for us is required. If there is a plugin out there that works and does this, refer to it. Don’t suppose we all know it.
A plugin that, actually, makes use of those 10K posts and tests this performance improvement with functions like microtime and get_num_queries (including SAVEQUERIES)
This could feel pretty obvious, but these two parts are essential to building a Testing Use-Case for performance upgrades. And it’s still surprising the massive number of times that they cannot be found in the Performance tickets. Simply don’t expect anyone to write them for you. Take the lead and send it the whole pack by yourself: the patch + the plugin with performance tests. Otherwise, there is a big risk that the ticket ends forever in the forgotten box of unreleased patches.
More examples in the future will be provided as they become available because some categories, like the Back-End Enhancements and New Features, certainly need them.
If you have any comments, any questions, or any ideas to improve this guide on how to build your Testing Use-Case, please comment.
Props to @oglekler and @audrasjb for helping review this article and offering feedback
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Here’s a roundup of active tickets that are ready for testing contributions.
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.
Reproduction Testing 🔁
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:
Who? Any QA or PHPPHPPHP (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. https://www.php.net/manual/en/preface.php. developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe 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 CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team is planning to set up a release squad, a plan/scope and a schedule for 6.8.2 (and beyond)
Call for 6.8.x Release Managers is still open. Anyone interested to lead a 6.8.x release can drop a comment in this P2P2P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/. post.
Upcoming Meetings 🗓
🚨 There will be regular #core-test meetings held for 2025.
At the moment while writing this post, there are 9 tickets in the 6.8.2 milestone on Trac. Bug fixes currently located in milestone 6.9 can probably start to be moved to 6.8.x milestones, but 6.8.2 will most probably still be focused on remaining issues/regressions found on 6.8.
#core-editor team has shared this for the issues that needs testing. Please feel free to pick and contribute to any tickets and make sure to update the same in the #core-editor for the better visibility.
@sirlouen shared an update to the team that the new keyword has already been updated. Reports containing the old keyword will not be automatically updated and will need to be revised manually. He also mentioned that if any old keywords will be encountered then he will handle that part.
SirLouen requested @OGlekler to remove the -needs-testing-info keyword from the weekly reports.
The new list of keywords to use is: needs-testing has-patch -dev-feedback -2nd-opinion -close -needs-refresh -needs-design -needs-design-feedback
6. Questions/Blockers
@sirlouen raised a concern that many test reports genuinely needing attention are being overlooked, while others are already tested number of times but are still being retested which indeed does not add any value. To address this, he proposed manually curating a list of reports that actually need testing and will share clear, straightforward testing instructions to help non-technical testers contribute effectively.
In response, @krupajnanda thanked @sirlouen for volunteering to curate the list and requested that the list be posted in the channel once ready, so it can be pinned and easily accessed by others. (The list has already been pinned)
In a recent discussion, @sirlouen proposed a new initiative to host public Patch Test Scrub sessions dedicated to testing patches. Participants will be able to:
Join a scheduled session and test patches live alongside others.
Ask questions and get real-time guidance especially for more complex patches.
The very first Patch Test Scrub is scheduled for Monday, May 12th at 3PM GMT (5PM CEST / 8:30PM IST) and will be facilitated by @sirlouen. Future scrubs may adapt based on feedback and participation that we will receive.
At the moment while writing this post, there are 9 tickets in the 6.8.2 milestone on Trac. Bug fixes currently located in milestone 6.9 can probably start to be moved to 6.8.x milestones, but 6.8.2 will most probably still be focused on remaining issues/regressions found on 6.8.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Here’s a roundup of active tickets that are ready for testing contributions.
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.
Reproduction Testing 🔁
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:
Who? Any QA or PHPPHPPHP (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. https://www.php.net/manual/en/preface.php. developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe 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.
At the moment while writing this post, there are 9 tickets in the 6.8.2 milestone on Trac. Bug fixes currently located in milestone 6.9 can probably start to be moved to 6.8.x milestones, but 6.8.2 will most probably still be focused on remaining issues/regressions found on 6.8.
Upcoming Meetings 🗓
🚨 There will be regular #core-test meetings held for 2025.
Hello and welcome to another edition of Week in Test, the place where contributors of any skill level can find opportunities to contribute to WordPress through testing. You can find the Test Team in #core-test.
Calls for Testing can originate from any team, from themes to mobile apps to feature plugins. The following posts highlight features and releases that need special attention:
Here’s a roundup of active tickets that are ready for testing contributions.
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.
Reproduction Testing 🔁
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:
Who? Any QA or PHPPHPPHP (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. https://www.php.net/manual/en/preface.php. developer contributors who can (or are interested in learning how to) build automated PHPUnit tests. Why?Automated tests improve the software development feedback loopLoopThe 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.
WordPress 6.8 is already out. If you come across any issues, please report them on Core Trac or GitHub.
The GutenbergGutenbergThe 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/ 20.7 is now available – https://wordpress.org/plugins/gutenberg/
8. Discussion
During the meeting, @sirlouen raised the issue of the Workflow Keywords, specifically around the keyword needs-testing-info, which has been causing confusion due to its similarity with needs-testing. Two solutions were proposed, with the renaming of the keyword considered the most viable. Here, the objective is to enhance usability and maintain clarity in the keyword naming scheme. @joemcgill suggested the keyword needs-test-info, as it aligns better with the current format of existing workflow keywords.
A quick poll was conducted during the meeting, and the majority voted for the following naming convention:
needs-test-info
has-test-info
These changes will align testing-related keywords with the overall naming scheme used in the project.
@krupajnanda asked whether the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. team would support implementing these changes once the updated keywords and their intended usage are shared. @joemcgill confirmed his willingness to assist with this.
@sirlouen mentioned that once @muddassirnasim completes the meeting notes, he will forward the information to @dd32 for inclusion in the official TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. documentation.
WordPress 6.8 is already out. If you come across any issues, please report them on Core Trac or GitHub.
The GutenbergGutenbergThe 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/ 20.7 is now available – https://wordpress.org/plugins/gutenberg/
Discussion
@sirlouen mentioned the Workflow Keywords issue and proposed two solutions. This was recently discussed during core dev chat meeting. Out of the proposed solution renaming the keyword seems doable. The goal is to improve usability and avoid confusion with the existing needs-testing and needs-testing-info keyword.
We’re planning to run a quick poll during the meeting to finalize the new keyword for needs-testing-info keyword.
Open Floor
Got a topic? Add in comments below, or bring it up live during the chat.
Leave a Comment
Do you have something to propose for the agenda?
Can’t make the meeting, but have a question for the Test Team?
If any of the above apply, please leave a comment below.