What a WooCommerce notice-placement test matrix should actually cover

Notice27 by Kastovia — Sat, 15 Aug 2026 04:49:39 +0000

I work on Notice27, and one lesson from testing notice placement in WooCommerce is that “it appeared at checkout” is not a meaningful acceptance test.

A store can have a classic product template, a block-based cart, a shortcode checkout, extension-managed line items, translated routes, and customer order views—all in the same installation. Each surface has different rendering and state-change behaviour.

This is the practical test matrix I now use before treating a notice workflow as implementation-ready.

1. Map the real customer surfaces

Start with the routes that customers actually use:

simple and variable product pages;
mini-cart or cart drawer, if present;
full cart;
Classic Checkout and Checkout Block;
order-pay and order-received routes;
customer account order details;
transactional email, if the implementation intentionally includes it.

Do not infer coverage from one route. A clean product-page result says nothing about a Checkout Block integration.

2. Separate Classic and Block paths

WooCommerce Blocks are not just a visual variation of the classic shortcode flow. They use different extension points and update behaviour. Treat these as separate test families:

Surface	Minimum checks
Classic cart	initial render, quantity update, item removal, coupon update
Cart Block	initial hydration, quantity change, item removal, extension data refresh
Classic checkout	initial render, address change, validation error, payment-method change
Checkout Block	initial hydration, address change, validation state, payment-method change

If a store supports both paths during a migration, both need evidence.

WooCommerce’s extension documentation is the right starting point for Block integrations: Extending the Cart and Checkout Blocks.

3. Build rows around facts, not ideal products

A useful matrix includes ambiguity and failure states:

simple product with complete reviewed facts;
variable product where variations resolve differently;
variation selected, changed, and cleared;
mixed cart with different product states;
missing product or market fact;
unsupported or unresolved language;
merchant decision still awaiting review;
stale configuration after a product edit.

The important result is not always “show the notice.” Sometimes the correct implementation result is a visible review-required state. Missing inputs should not silently become a legal conclusion.

4. Keep distinct decisions distinct

In the Notice27 workflow, the harmonised EU legal-guarantee notice and the separate GARAN durability label remain separate review paths. A decision about one does not establish eligibility or required use of the other.

Digital content, digital services, goods with digital elements, and software-update information also need their own classification and review. The software should preserve those distinctions rather than flattening them into one “covered” flag.

That is an implementation principle, not a claim that software can determine whether a specific transaction is legally in scope.

5. Test interaction, language, and accessibility together

For every approved row, exercise the state changes a customer can trigger:

add the item from the product page;
change a variation or quantity;
remove and restore items;
change billing or shipping country where relevant;
switch storefront language;
trigger validation errors;
navigate by keyboard;
zoom to 200%;
repeat on a narrow viewport.

Long translations are especially good at revealing fragile layouts. Check that the notice does not obscure the price, variation controls, quantity input, add-to-cart action, order summary, or payment controls.

For accessibility expectations, use the WordPress Accessibility Coding Standards as a baseline, then test the actual theme and extension combination.

6. Record repeatable evidence

A screenshot alone is weak evidence. For each matrix row, record:

WooCommerce and WordPress versions;
active theme and relevant extensions;
route and viewport;
product or variation state;
market and language inputs;
expected result;
actual result;
reviewer and date;
screenshot or short recording;
unresolved questions.

This makes regressions easier to diagnose after theme, checkout, or merchandising changes.

A public implementation demo

I built a resettable Notice27 demo to make these states easier to inspect:

Open the fictional-product demo

It collects no payment and is intended for implementation evaluation. The workflow previews supplied notice assets across product, cart, Classic/Block checkout, and customer order views while keeping unresolved inputs visible for review.

Disclosure and scope: I work on Notice27. Notice27 is implementation software, not legal advice, certification, automatic national-law coverage, official approval, or a guarantee of compliance. A merchant and its advisers remain responsible for applicability under the relevant national law.

If you maintain WooCommerce stores, which matrix row has caused the most surprising failure in your stack?

DEV Community: Notice27 by Kastovia