An Acceptance Criterion With No Implementation Surface
One criterion had no implementing code anywhere in the class that owned the calculation. Another read as satisfied while the query quietly dropped every promotion.
The story had a criterion about waived charges. There was nothing to click.
Not a broken screen. Not a failing assertion. Nothing at all — no field to inspect, no record to compare, no place where the behaviour would have appeared if it worked.
What the Story Was For
An early termination charge is what a customer pays for leaving mid-contract. The story existed because that charge has to fold in the special promotions the customer held while they were in contract. Otherwise the person walking out of the door is billed against a price they never actually paid.
That is not a preference. It comes from the regulator, and it is the sentence that justified the entire piece of work.
Six acceptance criteria. Five of them describe something you can drive from a cart.
The sixth says that a waived charge must push its discount through to the billing system.
Searching for a Feature Instead of Exercising One
There was no scenario I could build that would show me whether the sixth criterion was met, because there was no output it would have changed. So I stopped trying to construct one and searched the Apex for "waiver" instead.
One result. An activation-fee waiver belonging to an unrelated product line, in a different part of the codebase, doing a different job.
Nothing in the class where the rest of the charge calculation lived. Nothing anywhere in that layer.
The criterion had no implementation surface.
Why an Absence Survives Every Test Suite
This is the part worth sitting with. A missing feature leaves no artefact.
There is no field showing the wrong value, no error in a log, no orchestration item stuck in a state you can screenshot. There is only a shape in the requirement with no matching shape in the build — and a suite assembled by exercising what exists is built entirely out of things that are there.
The only way to see it is to run the comparison in the other direction. Take each acceptance criterion and go looking for the code that should satisfy it. Then record what happens when you find none.
That reframes the conversation usefully. "Does the waiver work" has no answer and produces a week of environment-hunting. "Where does the waiver live, and who owns that layer" has an answer, and it is a question somebody can be handed.
The Second Finding, Which Was Worse
Reading the calculator class for the sixth criterion put me inside the code for the first one.
The query that retrieves the customer's in-contract offers filters Source != 'Promotion'. Duration is derived only where Source == 'Discount'.
So an in-contract offer stored as a Promotion on OrderPriceAdjustment never enters the calculation at all. It is dropped, silently, and the termination charge comes out too high — on exactly the customers the criterion was written to protect.
The requirement that justified the story was inverted by the story's own implementation.
What It Was Not
It was not an error. No red banner, no failed job, no null.
The screen shows a number, and the number is plausible. The acceptance criterion reads as satisfied, because a charge was calculated and displayed and the arithmetic on screen is internally consistent. The happy-path check reconciles to the penny — because the promotion used to build that scenario happened to be stored as a Discount, which is the one type the query accepts.
Every signal a normal pass looks at agrees that the feature works. The defect is only visible if you read the SOQL filter and then ask how a real promotion is actually stored.
The Two Questions This Story Bought Me
Both findings came from the same half-hour of reading code, and both are now standing questions.
Which record type is this thing actually stored as? Not an implementation detail. A test condition. "Promotion" and "discount" are one word in the business conversation and two different records underneath, and any filter that names one of them has already made a decision about the other.
Where does this acceptance criterion live in the build? Ask it of the ones that carry regulatory weight first. A criterion that exists to keep you compliant earns a code-level read rather than a happy-path pass, because the failure mode you fear there is not a crash. It is a believable wrong number.
The most dangerous defect on that story produced no error, and the second most dangerous one produced no artefact at all.
Take the highest-stakes acceptance criterion on your current story. Can you point at the code that satisfies it?