Before the Retest, Ask the Org What Code It Has

A failed retest has two explanations, and only one of them is a bug.

Either the fix does not work, or the fix is not there.

The Question That Comes Before the Test

The change was to case owner assignment. The old logic worked by counting queues. The new logic recognises the user's Role.

Verifying it by hand means running the whole case-creation journey: build the right user context, walk the journey end to end, create the case, then read the owner off the record. It is not difficult. It is just long, and it has to be redone every time somebody says the fix has been deployed.

And at the end of it, if the owner is wrong, you still do not know what you are looking at. A stale org and a broken fix produce the same screen.

That ambiguity is the expensive part. A defect raised against a stale org comes straight back — the developer reads the code, sees the correct logic sitting right there, and returns it. Two people have then spent an afternoon establishing a deployment fact.

Reading the Answer Instead of Reproducing It

Deployment state does not have to be inferred from behaviour. It is sitting in the metadata.

So the check became a script. Retrieve the class, hash it, and look for source markers that only exist in one version or the other — the queue-counting logic on one side, the Role recognition on the other. Three outcomes:

• OLD — the markers of the previous implementation are present and the new ones are not. The fix is not in this org, and there is nothing to retest today.
• NEW — the new markers are present and the old ones are gone. The retest is worth starting, and if it fails, the failure is about behaviour.
• MIXED — both sets of markers are present. Stop and read it by hand.

Seconds, repeatable, and it answers the only question that was ever blocking the retest.

MIXED is the outcome I would defend hardest. A diagnostic that always returns a confident verdict is a diagnostic that will one day be confidently wrong — a partial deployment, a merge that kept both branches, a class someone edited in the org. Letting the tool say "I do not know, look at this" is what makes the other two answers trustworthy.

The Same Script, Pointed at the Tests

Once you are already reading source, the test class costs nothing extra to read.

Two things came back. The first: the owner-assignment tests are behavioural. They insert a case, then assert the resulting OwnerId against a queue. They never call the method by name.

That is not a fault — asserting the outcome is usually better than asserting the call. But it does mean you cannot establish what is covered by searching for a method name. "Is assignOwner tested?" has no grep-shaped answer. Somebody has to read what the tests actually do, and knowing that in advance is worth having.

The second finding was the one with teeth: the script counts commented-out assertions in the test class.

"All tests passing" can be perfectly true because an assertion was muted. A commented-out assert is invisible to every signal a build produces — the test still exists, still runs, still reports green — and it is usually commented out at the exact moment it started failing, which is the moment it was doing its job.

What Made This Worth Automating

Nothing here required a tool that did not already exist. Metadata retrieval, a hash, a search for a handful of strings. The insight is not technical.

It is that a whole class of QA question is deterministic and does not need a manual journey to answer. Which version of this class is in the org. What does this suite assert. How many assertions are switched off. Those are facts about text, readable without reproducing anything, and we habitually answer them the slow way — by running the system and inferring backwards from what it does.

Reproduction is for behaviour. State is for reading.

The Pre-Flight Habit

Before a retest, spend the thirty seconds that tells you whether the retest is worth starting. Before trusting a green suite, spend the thirty seconds that tells you whether it still asserts anything.

Both checks are the same move. Ask the artefact directly instead of asking the system to perform for you.

The first one saves an afternoon of walking a journey against code that was never deployed. The second one catches a muted assertion, which is an escaped defect that has not chosen its date yet.

How do you currently know that the fix you are retesting is actually in the org?