> ## Documentation Index
> Fetch the complete documentation index at: https://docs.smartwpplugins.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How we test
> The reviews, automated tests, release checks and performance measurements behind each release
Admin Powerups touches orders, customer accounts, emails and checkout, so every release goes through reviews, automated tests, release checks and performance measurements before it ships.
## What "tested" means here
A release is ready only when:
* every automated test passes in all four setups we support, on MySQL and on MariaDB, and with a persistent object cache,
* every release check passes,
* the independent security, QA, performance and code reviews have no open release-blocking findings.
A check that couldn't run is reported as **not tested** and never counted as a pass.
## How a change gets to a release
Before building, the change is planned, and security, QA and performance plans are written for it.
The change ships with its own tests. Every power-up has its own test file.
Separate security, QA, performance and code reviews look at the change. Anything that touches customer data, orders, permissions, deletion, exports or account switching always gets a security and a QA review.
Findings are fixed, then checked again by the review that raised them.
All automated tests and release checks run on the final code. The result is "ready" or "not ready". Nothing ships as ready while a check is failing.
## Automated tests
The 1.0 release has more than 1,800 automated PHPUnit tests. They run against real WordPress and WooCommerce, in four setups:
| Setup | Why |
| - | - |
| High-performance order storage on | WooCommerce's default for new stores |
| High-performance order storage with sync to posts | Stores that keep both order tables in step |
| Legacy posts storage | Stores that haven't switched yet |
| WordPress multisite | Per-site power-ups and stricter user permissions |
Tests that need High-performance order storage, such as Advanced order search, are skipped in legacy mode with a reason.
The suite also runs on MariaDB, and with a Redis persistent object cache. Both give the same results as on MySQL.
### PHP and database versions
For 1.0.0, with WordPress 7.1 and WooCommerce 11.1, the full suite passed on each of these versions:
| Software | Versions |
| - | - |
| PHP | 8.1, 8.2, 8.3, 8.4 and 8.5 |
| MySQL | 8.0, 8.4 and 26.7 |
| MariaDB | 10.5, 10.6, 10.11, 11.4, 11.8 and 13.0 |
On PHP 7.4 and 8.0, WordPress refuses to activate the plugin. If a host later moves a site below PHP 8.1, the plugin shows a notice and stops loading. Its data is kept. See [Requirements](/admin-powerups/getting-started#if-php-or-woocommerce-drops-below-the-minimum).
### What the tests cover
* each power-up's rules, settings, tools, emails and background jobs
* power-ups used together: checkout and email combinations, the order lifecycle, and activating, deactivating and updating the plugin
* both checkouts: anything that changes checkout is tested in the classic checkout and the block checkout
* settings stored in an unexpected type, which every settings form must still handle
* power-ups that are off, which must leave no hooks behind
### Security tests
Separate suites also try to break things on purpose:
* A permission matrix calls every REST, AJAX and admin-post endpoint as a logged-out visitor, a customer and staff. New REST routes are picked up automatically.
* Input fuzzing sends odd input to endpoints and settings forms, such as quotes, HTML, emoji, very long text and huge numbers.
* The order and customer search types are tested with SQL injection attempts.
* Output is checked for escaping, and masked order meta must never appear in the page.
* Switch to customer is tested for permissions, privilege escalation, tampering, password changes and the full switch-and-back cycle with real sessions. See [Switch to customer](/admin-powerups/switch-to-customer).
* Adversarial suites try to misuse every Developer and Performance tool, Quick stock, Analytics order filters and the payment and shipping rules.
* Absurd page numbers and amounts too large to handle are tried on paged screens and in the order and customer searches.
## Real-browser tests
117 end-to-end tests drive a real WooCommerce site in a browser with Playwright. They cover the Powerups screen, settings, payment and shipping rules, block checkout, the checkout blocklist, holiday mode, the Orders and Users lists, emails, the order screen, switching to a customer, the customer tools, Quick stock, Analytics order filters, and the Developer and Performance tools.
The tests snapshot the site's power-up settings before they start and restore them exactly afterwards. Everything they create is marked and removed. If the settings don't match the snapshot, the run fails.
## Code quality and security checks
Every release runs these checks:
| Check | What it looks for |
| - | - |
| PHP lint | Syntax errors |
| PHPCS with WordPress Coding Standards and PHPCompatibilityWP | WordPress coding rules, escaping, sanitizing, PHP version compatibility |
| PHPStan, level 6 | Type and logic errors, with WordPress and WooCommerce stubs and no baseline of ignored errors |
| ESLint (WordPress rules) and Stylelint | JavaScript and CSS problems |
| Semgrep | Security patterns in PHP and JavaScript, leaked secrets, plus custom WordPress rules |
| gitleaks | Secrets committed by mistake |
| composer audit and npm audit | Known vulnerable dependencies |
| Build check | No development files in the package, and every class loads |
| Plugin Check | The official WordPress.org tool, run on the built package: 0 errors |
## Performance
We measure performance with a probe that counts the plugin's own database queries on each page. Results are medians of repeated warm runs, with no persistent object cache.
### Your storefront
With every power-up on, the plugin adds 0 database queries to the front end and the Store API (the block cart and checkout). Page time and memory stayed within run-to-run noise.
### wp-admin
* Most admin pages: 1 to 4 plugin queries. The settings load in one query.
* Orders list: 1 query.
* Users list with every customer column on: 9 queries per page, however many users are listed.
### A large store
We also test on a store with 100,000 orders, 50,000 customers and 10,000 products (plus 1,500 variations), using High-performance order storage. It also holds about 3.5 million order item details, 200,000 comments and 300,000 scheduled actions. The last run used MySQL 8.4, PHP 8.2 and a Redis object cache. Times are medians of five warm runs. They include the 0.3 to 0.4 seconds WordPress and WooCommerce take to load on each request.
| Screen | Without the plugin | With the plugin |
| - | - | - |
| Orders list | 0.38 s | 0.39 s |
| Users list with all 12 customer columns | 0.37 s | 0.39 s |
| Analytics → Orders, one year, without the report cache | 0.49 s | 0.52 s |
| Power-up | What we measured | Time |
| - | - | - |
| Advanced order search | Order number, customer ID, status or a total | 0.5 to 0.8 s |
| Advanced order search | Customer, email, company, SKU or notes | 0.5 to 0.7 s |
| Advanced order search | Phone, product, coupon or shipping method | 0.9 to 1 s |
| Advanced order search | Variation text | 1.1 s |
| Advanced customer search | Each of the 13 types | 0.5 to 0.7 s |
| Analytics order filters | One year by country, state, city, payment method or guests | 0.5 to 0.6 s |
| Analytics order filters | One year by shipping method type, or with all six filters | 0.9 s |
| Analytics order filters | One year by customer role | 1 s |
| Analytics order filters | One year by one shipping method in one zone | 1.6 s |
| Quick stock, Autoloaded options, Scheduled action monitor, Cron inspector | Opening, filtering and sorting their tabs | 0.4 to 0.5 s |
| Duplicate customer finder | Scanning all 50,000 customers | 184 steps, 76 to 99 s in total |
| Database clean-up | Scanning all 24 checks offered on this store | One step, about 3 s |
| Test data | Making 200 products, 500 customers and 2,000 orders | About 3 minutes, in 80 steps |
| Test data | Cleaning that batch up again | About 1.5 minutes |
* Run cold, before the database had its tables in memory, the same order searches took 2 to 5.6 s.
* Database clean-up emptied every check, in steps that stop near their 5-second limit (the longest took 5.7 s). It deletes rows directly at 10,000 to 80,000 a second. Revisions, posts and comments go through WordPress, at about 140 to 1,000 a second.
* No request or step used more than 128 MB of memory. The most was 112 MB.
### Fixes from these tests
Each row compares the code before and after a fix, on a store of the same size. The last three rows were measured inside WordPress, without the time it takes to load a page.
| What we checked | Before | After |
| - | - | - |
| Scanning 50,000 customers for duplicates | Ran out of memory | Completes in small steps |
| Searching orders by product ID, SKU, variation ID or shipping method | 1.4 to 5.7 s | 0.24 to 0.62 s |
| Searching orders by variation attribute text | 6.8 s | 2.5 s (marked Slower) |
| Searching custom order meta as staff who can't see masked keys | Up to 24.7× slower than an admin | 1.0 to 1.35× the admin's time |
| Clearing 465,000 old email log entries | Runs that had to be stopped | 20-second runs, cleared in 5 |
| Opening an order with 300 items | 855 ms | 428 ms |
| Block cart with a variation | 1 plugin query | 0 |
| Searching custom order meta for one exact value | 1.9 s | 0.3 s |
| Database clean-up example rows, when the leftovers sit at the end of a big table | 1.3 to 1.4 s | 8 ms |
| Deleting 159,000 completed scheduled actions | About 11 steps | 2 steps, 8.5 s |
Settings that can still be slow on big stores carry a warning or a **Slower** badge. See [Performance](/admin-powerups/performance).
## Privacy and your data
* Each power-up lists what it stores. The Data section on its page and the uninstall both read that list, and tests check every power-up's list. See [Data and uninstall](/admin-powerups/data-and-uninstall).
* The plugin never deletes customer accounts, saved addresses, order statuses or order notes. Tests check uninstall with and without **Keep data if the plugin is deleted**.
* Order meta keys that look like tokens, passwords, secrets or card details are hidden in the [order meta inspector](/admin-powerups/order-meta) unless you allow staff to reveal them. Staff who can't reveal them can't search them with [Advanced order search](/admin-powerups/advanced-order-search) either. Tests check that masked values never reach the page.
* Emails with a password or verification link (new account, password reset, email address confirmation and back-in-stock sign-up verification) are never stored with their content, copied to extra recipients, previewed, test-sent or offered for resend.
## What we haven't tested yet
* Large stores that keep orders in legacy posts storage, or sync orders to posts. The automated tests run in both, but we measured performance on a large store only with High-performance order storage.
* MySQL 5.7, and Database clean-up's speed on MariaDB with large tables.
* A store ten times the size above. We expect a full Database clean-up scan there to take 30 to 40 seconds, in 6 to 8 steps.
* Slow shared hosting, or a database whose tables aren't in memory yet. Database clean-up steps still stop at their time limit, so a scan takes more steps.
* Multisite networks with thousands of sites, where Database clean-up has to list thousands of tables.
* Quick stock with 100,000 products. We expect about 0.6 to 0.8 s of database time for its default view.
* Test data's check of real orders on a store with 30 million order item details (we expect 7 to 8 s over 2 to 3 steps), and its Clean up tab with the maximum of 50 batches.
* Passing tests and reviews mean we found no known release-blocking problems. That isn't a guarantee there are none, so please tell us if something goes wrong.
## Report a problem
Post on the [WordPress.org support forum](https://wordpress.org/support/plugin/admin-powerups-for-woocommerce/) with your system info from **Copy for support** in the sidebar's System card. Threads are public, so leave out customer details. If a report would expose a security problem, don't post the details publicly; email it to [support@smartwpplugins.com](mailto:support@smartwpplugins.com) instead.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.