How to test promo codes and restore the best result

ShopTools AI compares totals before and after a coupon test on a supported page. The reviewed code distinguishes a decrease from acceptance without measured savings. An engineer also needs to leave the cart in a verifiable state.

The following is a reference algorithm for reversible testing. State names define a proposed contract, not the fields present in every installed ShopTools version. Verify the behavior of a particular build with separate tests.

Capture the baseline before making changes

The baseline needs a positive total, currency, reading source and evidence of any existing code. Store and operation context prevent comparisons between different carts after navigation. An individual item's price is not the order total.

A change in currency, total source or order contents invalidates the comparison. A missing starting total is a reason to stop. An accepted message records a store response, but it cannot replace a measured decrease.

Define transitions and candidate evidence

1. Locate a safe field and capture the baseline. Prepare a bounded queue and require a user command to start.
2. Persist the awaiting-result state before submission. Then enter the code, perform the permitted apply action and wait for a stable response.
3. Record before, after, currency, reason and queue position. Keep measured reductions separate from acceptance without measurement.
4. Compare like-for-like results only. Resolve equal totals using a defined queue order, not whichever response happened to arrive first.

Reset is a precondition for another attempt

Before the next code, remove the active coupon through a safe action and confirm a comparable baseline. Clearing an input does not establish that the retailer removed the promotion. Read the total again after recalculation.

Enter safe_stop if the baseline cannot be restored. Do not keep combining unknown effects. Retain a useful result only while the current cart still verifies it; otherwise hand control back for manual inspection.

A reload does not authorize another submission

Before possible navigation, persist the queue, index, baseline, pre-attempt evidence, awaiting_result and operation identity. Give the record an expiry. Keep form contents and payment details out of the technical log.

After loading, check expiry, host and checkout context. Evaluate the interrupted attempt before deciding whether to advance. A hostname alone cannot distinguish two independent carts at the same retailer.

Make completion idempotent so another reload cannot resubmit a processed code. A different tab, a login redirect or expired state does not authorize resumed mutations. Clear completed pending records.

Verify the winner again

The lowest observed total may belong to a code removed earlier in the test. In restore, apply the selected code again and compare it with the original baseline. A stored record of a previous success is not a fresh observation.

If reapplication cannot be verified, record restore_failed. Remove the old saving message, stop automatic mutations and ask for a cart check. Do not claim that clearing the input restored the price without measuring again.

A minimum reproducible test set

• Two codes lower the total, but the winner is not last; the verified winning code is active at completion.
• A code is accepted without a decrease, currency changes or the total later returns to baseline: no monetary success is recorded.
• There is no remove control or reset fails to recover baseline: no further apply action occurs.
• Reload after submission, two tabs, expired pending state and repeated startup: no duplicate submission or cross-cart recovery.
• The winner is rejected on reapplication: the final status reports restoration failure rather than an earlier saving.