Test the Edit, Not the End State

The cart looked identical to a cart that had never been touched.

Same bundle. Same quantity. Same total. The order went through, the billing system's Create Order callout fired automatically and completed cleanly, and every screen in Salesforce said the same thing: fine.

The invoice was wrong.

What Actually Happened to That Cart

A promotion bundle was added, removed, and added back again before submit.

That is it. That is the entire reproduction. No unusual product, no unusual pricing, no interrupted session, no error at any point in the flow.

The end state of the cart was a perfectly ordinary configuration — one that had been tested, more than once, and that worked every time it was built in one pass.

Where the Evidence Was Not

The reason this one is worth writing down is not the defect. It is where the defect was visible.

Not in the cart. Not on the order. Not in the order line items, not in the orchestration, not in the callout response. The callout did not warn, retry, or partially fail. It returned success, because success is what it was: the message was accepted.

The residue of the deleted line only became visible one system downstream, on the invoice.

So every signal a tester normally uses to decide whether an order is healthy was green, and all of them were telling the truth. They were reporting on the thing they measure. None of them measures what the receiving system does with what it was sent.

What This Was Not

It was not a failed integration. The integration worked.

It was not a configuration gap either — the same bundle, built without the remove-and-re-add, billed correctly. And it was not a data problem a tester could have found by inspecting the record, because the record that came out the other side of the edit read as clean.

The difference that mattered was not in the final contents of the cart. It was in the history of how those contents got there.

Why No Test Case Covered It

Because of how test design usually decomposes a feature.

You take the configurations — the bundles, the discount types, the add-ons — and you cover each one once. Build it, submit it, assert the outcome. The cart is treated as a form: fill in the fields, press submit, and what matters is what the fields contained at the moment you pressed it.

Under that model, "bundle removed then re-added" is not a separate case. It is the same case, reached by a slightly clumsier route, and nobody writes a test case for a clumsier route to a state they have already covered.

That is exactly why the defect survives. It lives in a state that no test plan intends to visit, and that every real user reaches by accident.

A cart is not a form. It is a sequence of operations against a record graph, and each operation leaves something behind. "This line was never here" and "this line was here and was deleted" produce carts that look identical and record graphs that are not — and that difference is precisely the kind that survives a clean handoff into billing.

The Cases to Add

For any cart, configurator, or basket that feeds a downstream system, add the mutation cases explicitly. There are only four verbs and they generate almost all of it:

• Add, remove, re-add the same item. The one that produced this defect. It is the most natural user behaviour in the entire list — people change their minds — and it is the least likely to be in a test suite, because the finished cart is indistinguishable from an untouched one.
• Change quantity up and back down. Same principle, applied to a field rather than a line. Ending where you started is not the same as never having moved, and if it is, that is a fact worth proving once rather than assuming forever.

Two things make these cases work. The end state must be one you already have a passing test for, so any difference in outcome is attributable to the edit and nothing else. And the assertion has to sit downstream — on the invoice, on the artefact the customer receives. Assert on the cart and the cart will tell you what it told me: everything matches.

The Rule Worth Keeping

Test the edit, not the end state.

Every configuration your suite covers once, in one clean pass, is also reachable by a path involving a deletion — and a deletion is the only operation in the set that can leave something behind while showing you nothing.

How many of your test cases build the record in one pass, and how many of your users do?