Learning Objectives
By the end of this lesson, you will be able to:
- Find a current-milestone Trac ticket that has a patch but no test reports
- Reproduce a reported bug on trunk and document what you observed
- Apply a patch to a local WordPress install and verify the change actually ran
- Test edge cases beyond the original reproduction steps
- Write a test report with a complete environment block and before/after evidence, and tag the ticket appropriately
- Describe the ticket patch review commit workflow from having watched it happen
Why patch testing is the best first contribution
Most first contributions stall for the same reason: you need someone’s permission, or you need to wait weeks to find out whether your work was any good.
Patch testing has neither problem.
- No commit access required. Anyone with a WordPress.org account can file a test report. There is no gatekeeping step.
- Feedback lands in hours, not weeks. Committers actively look for tested patches when a release milestone is approaching. A good report gets read quickly.
- It earns real release credit. Test reports are counted as contributions, and contributors who test patches are credited in the release they helped ship. This is not practice work. It is the work.
- You learn the workflow by watching it. You will see a ticket move from reported, to patched, to tested, to reviewed, to committed — with your report as one of the steps that made it move. Reading about that process teaches you less than being inside it once.
Testing is also the bottleneck. Core routinely has more patches than people willing to verify them. Showing up to test is genuinely useful from your first day, which is not true of most ways into an open source project.
Before you begin
You need:
- A local WordPress development environment running trunk, not a stable release
- A WordPress.org account
- The ability to apply a patch or check out a pull request branch
- Debugging enabled (WP_DEBUG and WP_DEBUG_LOG set to true)
If any of these are not in place, complete the Developer Basics modules on local environment configuration and Git before continuing.
Step 1 — Find a ticket
Go to Core Trac and look for tickets that meet all three conditions:
- Assigned to the current milestone. These are the tickets a release is waiting on, so your report has immediate value.
- Has a patch. Look for the has-patch keyword, or a linked GitHub pull request.
- Has no test reports yet. The needs-testing keyword is the strongest signal. A ticket already carrying has-test-info has been covered — pick a different one.
Report queries on Trac and the Test team’s calls for testing on make.wordpress.org/test are the fastest ways to find these. Prefer a small, clearly described bug for your first attempt. A ticket with vague reproduction steps and eight attached patches is not where you want to start.
Comment on the ticket saying you are testing it. This prevents duplicate effort and signals to the committer that a report is coming.
Step 2 — Reproduce the bug on trunk
Before you apply anything, confirm the bug exists.
Follow the reproduction steps in the ticket exactly, on a clean trunk install. Then record what actually happened.
Three outcomes are all valid results:
- The bug reproduces. Good. You now have a verified “before” state to compare against.
- The bug does not reproduce. This is useful information, not a dead end. Report it, with your environment details, so the ticket owner can work out what differs between your setup and theirs.
- Something different happens. Also useful. Describe precisely what you saw rather than forcing it into the ticket’s framing.
Capture evidence at this stage — a screenshot, a screen recording, a copied error message, or the relevant lines from debug.log. You cannot go back and get the “before” state once the patch is applied.
Step 3 — Apply the patch
Apply the patch to your trunk install, or check out the pull request branch.
Then confirm the patched code actually loaded. This is not optional. A patch that failed to apply cleanly, applied to the wrong directory, or was cached away by an opcode cache will look exactly like a patch that did not fix the bug. Verify by checking that the changed lines are present in the file on disk, and that you are loading the files you just changed.
Step 4 — Test it
Start with the ticket’s reproduction steps. Does the bug still occur? Compare against the “before” evidence you captured.
Then go past the ticket. This is where a test report becomes valuable rather than merely present:
- Edge cases. Empty values, very long values, zero, negative numbers, special characters, non-Latin scripts, right-to-left languages.
- Roles and permissions. Does it behave correctly for an administrator, an editor, and a subscriber?
- Multisite. If the code path could plausibly touch multisite, test there too.
- Regressions. Does the surrounding feature still work? A patch that fixes one thing and breaks its neighbour needs to be caught now, not after release.
- Environment variation. A different browser, a different PHP version, a classic theme as well as a block theme.
- Errors. Check debug.log and the browser console. A fix that works but emits a notice is not finished.
Note anything surprising, even if you are unsure whether it matters. Deciding what matters is the committer’s job. Reporting it is yours.
Step 5 — File your report
Post your report as a comment on the ticket. Follow the test report format in the Test Handbook. At minimum, include:
A full environment block. Reports without one are frequently unusable, because a committer cannot tell whether your result reflects the patch or your setup.
WordPress version: [trunk, with changeset or commit hash]
Browser: [name and version]
Operating system: [name and version]
Theme: [name and version]
Active plugins: [list, or "none"]
PHP version: [version]
Server: [nginx / Apache, or your dev environment tool]
Database: [MySQL or MariaDB, and version]
Patch tested: Before and after evidence. Show the failure and then the fix. Screenshots side by side, a short recording, or clearly labelled output. Evidence is what makes a report verifiable by someone who was not there.
Your steps, as you actually performed them. If you deviated from the ticket’s steps, say so.
What you tested beyond the reproduction. List the edge cases you tried and the result of each, including the ones that passed.
A clear conclusion. Whether the patch resolves the issue, and any remaining concerns.
Then add the has-test-info keyword to the ticket. This is how other contributors and committers know the ticket has been tested. Leaving it off means your work may not be found.
If the patch does not work, report that with the same care. A well-documented failing test report is as valuable as a passing one — arguably more so, because it prevents a broken patch from shipping.
The verification rule
Never report a result you have not confirmed by running the code.
This rule exists because the failure mode is so easy and so damaging. Reading a patch and concluding it should fix the bug is not a test report. Assuming a change took effect because you saved the file is not verification. Reporting that something works when you did not watch it work misleads a committer who is trusting your report to make a release decision.
If you are using an AI assistant to help understand a ticket or a patch, the same rule applies with more force. An assistant’s confident explanation of what a patch does is not evidence that it does it in your environment.
Before you post, you must be able to answer yes to all of these:
- Did I see the bug happen before applying the patch?
- Did I confirm the patched code is present in the files being loaded?
- Did I see the behaviour change after applying it?
- Do I have evidence I could show someone else?
If any answer is no, either go back and do that step, or state plainly in your report what you could not verify. “I could not reproduce the original issue, so I cannot confirm the fix” is a respectable report. Implying you tested something you did not is the one thing that will cost you credibility in this community, and it is difficult to recover.
Definition of done
This lesson is complete when you have two accepted test reports on Core Trac:
- One reproduction report — you confirmed (or could not confirm) a reported bug on trunk, with environment details and evidence.
- One patch test report — you tested a patch on a current-milestone ticket, with a full environment block, before/after evidence, and edge cases documented.
Pass and fail results both count. A report concluding “this patch does not resolve the issue, here is what still happens” satisfies the requirement completely. You are being assessed on the quality of your testing and reporting, not on whether the patch happened to work.
“Accepted” means the report stands as a useful contribution to the ticket — it has not been asked to be redone for missing information. If a contributor asks you for more detail, provide it. That exchange is part of the learning, and the report still counts once complete.
Submit your work
- Open your individual tracking link.
- Select Lesson “Practical: Patch Testing.”
- Paste the URLs of both Trac ticket comments containing your reports.
- Note the hours spent and submit.
- Share the ticket links with your mentor on Slack so they can review your reports.
Key Terms
| Term | Definition |
| Trac | The ticket tracking system at core.trac.wordpress.org where WordPress Core bugs, enhancements, and patches are managed |
| Trunk | The in-development version of WordPress Core, ahead of the latest stable release; all testing for upcoming releases happens here |
| Milestone | The release a ticket is scheduled for; current-milestone tickets are the most urgent to test |
| Patch | A file describing proposed changes to the codebase, attached to a ticket for review and testing |
| has-patch | A Trac keyword indicating a ticket has a proposed code change attached |
| needs-testing | A Trac keyword indicating a patch is waiting for someone to verify it |
| has-test-info | A Trac keyword you add after filing a test report, marking the ticket as tested |
| Test report | A structured account of what you did, in what environment, and what happened, allowing others to verify your result |
| Environment block | The list of software versions and configuration under which a test was run |
| Release credit | Formal acknowledgement in a WordPress release for contributions, including test reports |
| Committer | A contributor with permission to commit changes to WordPress Core |
✅ Check Your Understanding
- You apply a patch and the bug no longer appears. What must you confirm before you can conclude the patch fixed it?
- Why is a failing test report valuable to the person who wrote the patch?
- A committer reads your report and cannot tell whether your result reflects the patch or your setup. What was most likely missing?