Title: Building the Testing Use-Case
Author: Manuel Camargo
Published: May 15, 2025
Last modified: July 4, 2026

---

 [  ](https://profiles.wordpress.org/sirlouen/) [Manuel Camargo](https://profiles.wordpress.org/sirlouen/)
7:22 am _on_ May 15, 2025     
Tags: good-practices, handbook, use-case   

# Building the Testing Use-Case

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 coreCore Core 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 WordCampWordCamp WordCamps 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](https://central.wordcamp.org/about/).
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.

 1. [Let’s dive into the Testing Use-Case](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#let-s-dive-into-the-testing-use-case)
 2. [Ideas to Build Your Testing Use-Case](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#ideas-to-build-your-testing-use-case)
 3.  a. [The Hook](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#the-hook)
     b. [Code Refactors](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#code-refactors)
     c. [Back-End Enhancements and New Features](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#back-end-enhancements-and-new-features)
     d. [Performance Upgrades](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#performance-upgrades)
 4. [Future Improvements](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#future-improvements)
 5.  a. [Changelog](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/#changelog)

## 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 pluginPlugin A 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/](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 HooksHooks In 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 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. [https://www.php.net/manual/en/index.php](https://www.php.net/manual/en/index.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:

 1. 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.
 2. If you would rather not showcase your code for copyright dilemmas with your client(
    funny in a GPLGPL GPL is an acronym for GNU Public License. It is the standard 
    license WordPress uses for Open Source licensing [https://wordpress.org/about/license/](https://wordpress.org/about/license/).
    The GPL is a ‘copyleft’ license [https://www.gnu.org/licenses/copyleft.en.html](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](https://en.wikipedia.org/wiki/Minimum_viable_product)
    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.

Do you want to review a Hook Testing Use-Case plugin example?
Check this one: [https://github.com/SirLouen/testing-41757/](https://github.com/SirLouen/testing-41757/)
Used in this report: [https://core.trac.wordpress.org/ticket/41757](https://core.trac.wordpress.org/ticket/41757)

### Code Refactors

There is a rule in the WordPress community: [never refactor if you don’t have a good reason for this](https://make.wordpress.org/core/handbook/contribute/code-refactoring/).
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):

 1. 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.
 2. 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.
 3. 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.

Do you want to review a Hook Testing Use-Case plugin example?
Check this one: [https://github.com/SirLouen/test-block-attributes/](https://github.com/SirLouen/test-block-attributes/)
Used in this report: [https://core.trac.wordpress.org/ticket/61154](https://core.trac.wordpress.org/ticket/61154)

### Back-End Enhancements and New Features

This categoryCategory The '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:

 1. 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.
 2. 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.

Do you want to review an Enhancement Testing Use-Case plugin example?
Check this
one: [https://github.com/SirLouen/testing-template-loading/](https://github.com/SirLouen/testing-template-loading/)
Used in this report: [https://core.trac.wordpress.org/ticket/58905](https://core.trac.wordpress.org/ticket/58905)
Also, this one: [https://github.com/SirLouen/wp-mail-embed-showcase/](https://github.com/SirLouen/wp-mail-embed-showcase/)
Used in this report: [https://core.trac.wordpress.org/ticket/28059](https://core.trac.wordpress.org/ticket/28059)

### Performance Upgrades

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 deployedDeploy Launching 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:

 1. 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.
 2. 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](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/#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.

Do you want to review a Performance Upgrade Use-Case plugin example?
Check this 
one: [https://github.com/SirLouen/wp-query-benchmarking-v2](https://github.com/SirLouen/wp-query-benchmarking-v2)
Used in this report: [https://core.trac.wordpress.org/ticket/18836](https://core.trac.wordpress.org/ticket/18836)
Also, this one: [https://github.com/SirLouen/image-memory-exhaustion-tester/](https://github.com/SirLouen/image-memory-exhaustion-tester/)
Used in this report: [https://core.trac.wordpress.org/ticket/24688](https://core.trac.wordpress.org/ticket/24688)

## Future Improvements

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_](https://profiles.wordpress.org/oglekler/)_ and _[_@audrasjb_](https://profiles.wordpress.org/audrasjb/)_
for helping review this article and offering feedback_

### Changelog

21/06/2025 – Added new New Feature Use Case

03/06/2025 – Added new Performance Use Case

08/05/2025 – Initial Article.

[#good-practices](https://make.wordpress.org/test/tag/good-practices/), [#handbook](https://make.wordpress.org/test/tag/handbook/),
[#use-case](https://make.wordpress.org/test/tag/use-case/)

### Share this:

 * [  Threads ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=threads)
 * [  Mastodon ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=mastodon)
 * [  Bluesky ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=bluesky)
 * [  X ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=x)
 * [  Facebook ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=facebook)
 * [  LinkedIn ](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?share=linkedin)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Ftest%2F2025%2F05%2F15%2Fbuilding-the-testing-use-case%2F%23respond&locale=en_US)

### Like this:

Like Loading…

 1. ![](https://secure.gravatar.com/avatar/63b312b80b349c169d9a624868c72b0c74c9e89d1ce84030c25cf95a82f6d645?
    s=32&d=identicon&r=g)
 2.  [Krupa Nanda](https://profiles.wordpress.org/krupajnanda/)  8:16 am _on_ May 15,
    2025
 3. +make.wordpress.org/core/

### Leave a Reply 󠀁[Cancel reply](https://make.wordpress.org/test/2025/05/15/building-the-testing-use-case/?output_format=md#respond)󠁿

You must be [logged in](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Ftest%2F2025%2F05%2F15%2Fbuilding-the-testing-use-case%2F&locale=en_US)
to post a comment.

# Post navigation

[← Week in Test: May 12, 2025](https://make.wordpress.org/test/2025/05/12/week-in-test-may-12-2025/)

[Week in Test: May 19, 2025 →](https://make.wordpress.org/test/2025/05/19/week-in-test-may-19-2025/)