Super Speedy Filters testing
Testing › Super Speedy Filters
Last full run: version 6.75.0 · 11 November 2026
Summary
Super Speedy Filters is tested in five layers: unit tests that check the plugin’s own rules, integration tests inside a real WordPress shop, smoke tests that install the plugin from a freshly built ZIP file on an empty site and request real pages over HTTP, an upgrade suite that installs the version customers are running today and updates it in place, and a test that deletes the plugin and checks nothing is left behind. This page describes those suites, what each one protects you from, and the result of the last run, including the tests that failed.
Every site runs real WordPress with WooCommerce and HPOS order storage switched on, except where a test is about sites without WooCommerce. Filters are checked by the products and posts they actually return, by the links and redirects the page actually sends, and by what is stored in the database afterwards.
The release run
| Suite | What it protects you from | How it runs |
|---|---|---|
| Unit tests | Mistakes in the plugin’s own rules: which filters show on which pages, term colours, SEO titles that must never go blank, category archives showing the wrong products, the SQL that counts products next to each filter, the redirect and indexing rules for filtered URLs, limits on hostile requests, loading cleanly on PHP 8.4 and later, and a check that every setting the plugin stores is removed when you delete it. | PHP, with the plugin’s real code |
| Shop integration tests | Faults that only show inside WordPress. A seeded shop with 120 products, categories, brands and four attributes, with filters placed by Auto Configure. Covers the filter count SQL against real tables, delayed filters on search results, the MCP and Abilities tools, hostile filter parameters never reaching a page as HTML, the archive gate’s rules, settings checkboxes that must untick, the auto-classifier never damaging existing filters, custom CSS staying inside the filters, SEO overrides, and category archives that must stay category archives. | WP-CLI inside WordPress |
| Fresh-install smoke tests | A plugin that works on our development site but not on yours. Each test builds a new WordPress, installs the plugin from a freshly built ZIP and checks real pages: product filtering, variations, pretty URLs, multi-select, pagination, custom post types, WP Job Manager, sites without WooCommerce, every widget, admin screens, rate limits for anonymous visitors, and real clicks in a browser. | New site per test, HTTP and browser |
| Upgrade suite | An update that breaks the settings you already have. Installs version 6.66.0, the version customers are running today, sets it up the way customers do (each AJAX mode, Plain permalinks, a read-only mu-plugins folder, grouped filters, Auto Configure), then updates in place the way WordPress does. Checks the settings carried over, the shop still filters, nothing is logged as an error and a second admin visit changes nothing. | Browser and WP-CLI, one new site per setup |
| Delete and reinstall | Data left behind, or a broken reinstall. Installs the plugin from a ZIP, uses it, deletes it through WordPress with the setting to delete all plugin data switched on, and checks that no table, setting or scheduled task is left. Then reinstalls it and checks archive pages log no database errors. | New site, WP-CLI and HTTP |
Last full run: version 6.75.0
Run on 11 November 2026 against the paid plugin, PHP 8.5, WooCommerce 10.5.3 with HPOS.
| Suite | Result |
|---|---|
| Unit tests | 11 of 12 passed. Three were broken tests, fixed and re-run (below). One real failure: settings left behind when the plugin is deleted (below) |
| Shop integration tests | 20 of 20 passed, and both category archive scenarios passed. One test was misreporting and was fixed (below) |
| Fresh-install smoke tests | 16 of 31 passed. 15 failed; the causes are below |
| Upgrade suite | 11 of 11 customer setups upgraded cleanly: 226 checks passed, none failed |
| Delete and reinstall | 12 of 13 checks passed. One failed: four settings are left behind when the plugin is deleted (below) |
Settings left behind on delete
Super Speedy Filters keeps a list of everything it stores so that deleting the plugin removes it all. A unit test reads every place the code saves a setting and checks it is on that list. It found settings added in recent versions that are not on the list: the filter groups, the filter layout, two records of one-off settings migrations, and a cached count used while filters load. We confirmed it on a real site: with the setting to delete all plugin data switched on, we deleted the plugin through WordPress and four rows were left in the database: the filter group records, their backup, and one migration record. Every table, scheduled task and other setting was removed. This does not affect how filtering works. It is a plugin fault and has been recorded for a fix.
The 15 smoke test failures
13 were written before Bot-fighting AJAX became the only AJAX mode in version 6.70.5 (10 November 2026). They ask for deep filtered pages directly, for example a category with a colour filter, and expect the filtered page back. Bot-fighting AJAX now answers that request on purpose with a redirect to the category page, and the browser then loads the filtered products in place with one request. That is how it stops bots crawling every combination of filters. The tests read the redirect as “no products”. We checked the same journeys in a real browser: clicking a filter shows the right products, and opening the redirected link again shows them too. The tests need updating to the new behaviour, and the WooCommerce browser test that already uses Bot-fighting AJAX passed (5 of 5).
One tests filtering by WP Job Manager’s job categories. In version 6.66.19 we stopped the plugin accepting filters, in the address, on taxonomies that WordPress marks private, because those could expose hidden term names. On this test site WP Job Manager registers its job categories as private, so the filter is now ignored. The test still expects the old behaviour and has not been updated, so it is listed as a failure.
One checks that a stripped-down AJAX request never saves incomplete permalink rules. The rules were never damaged. The test’s other expectation, that a pending permalink refresh is left for later, failed because a full WordPress request ran the refresh first: one the test now sends since version 6.70.7 stopped trimming plugins on page requests, and a scheduled-task request WordPress started by itself. That is the correct result, so the test needs updating.
Tests we fixed
Four tests were themselves wrong. None of the fixes changed plugin code, so the version is still 6.75.0. Each fixed test was re-run and passed, and each was then made to fail by deliberately breaking the plugin code it guards, so it can still catch a real fault.
- Three unit tests for SEO titles and category archives had stopped running at all. Since version 6.66.19 the plugin checks whether a taxonomy may be filtered from the address, and these tests never loaded that check, so they stopped with an error before their first assertion. They now load the real check.
- The delayed-filters-on-search test reported all six container types as broken on a working build. Since version 6.69.0 a delayed filter shows grey placeholder rows while it loads, and the test mistook those for a filter that had loaded too early. It also exited as a pass while printing a failure. It now tells placeholder rows from real filter links, and a failure fails.
One more test, on how the shared settings screen caches the changelog, was run with WooCommerce switched off. It starts WordPress’s admin start-up step from the command line, which WooCommerce does not support outside the admin area, so it crashed inside WooCommerce. With WooCommerce off it passed.
Not part of this run
- Lite, the free edition. Building the Lite ZIP runs its release checks, so the Lite suites were not run.
- Release checks on the ZIP file. The packaging checks run before a ZIP is published.
- Bug regression tests. Each fixed customer bug has its own test on its own site, many with the theme or plugin it was reported with: WPML, Polylang, Elementor, Enfold, WCFM, Product Bundles and others. They run when the code they cover changes.
- Feature suites for filter groups, the layout editor, multisite, multilingual shops and sitemaps, and the performance tests on a one-million-product catalogue.
What the tests do not cover
- Your server. Tests run on our development machine with one PHP version and one MariaDB version, not every host and database you might use.
- Every theme. Smoke tests run on a mix of common themes, such as Storefront, Astra, OceanWP, Neve and the Twenty Twenty themes. Your theme may place filters differently.
- Every other plugin. Plugins we integrate with are tested where a suite names them. Other plugins on your site are not.
