Test hardening

[NickSdot]

Test files sweep to make exception assertions more robust, and slightly unify style.

Specifically:

• adds thrown class to all exception assertions to protected against regressions
• further established the already recommended single exception formatting
• adds missing last line whitespaces were missing

Target format:

echo $e::class, ': ', $e->getMessage(), PHP_EOL; // + variations like line(), code(), etc.

Approach:
Rewrites are handled by this deterministic helper for conservative and safe, automated replacements. All exception assertion "flavours" from php-src were extracted, and the tests where they were found promoted to source fixtures. Rules were then ran against the fixtures, the results manually reviewed, and promoted to target fixtures. All replacement rules are tested against the source and target fixtures. The actual "fixing" works as follows:

1. Scan PHPT files for exception-message output inside catch blocks.
2. Run the original PHPT through run-tests.php; skipped or already failing tests are not rewritten.
3. Rewrite the PHPT to the normalised exception-output shape.
4. Run the rewritten PHPT through run-tests.php.
5. If output changed as expected, update the expected section from the actual run output.
6. Run the updated PHPT once more.
7. Keep only rewrites that pass verification.

Modules & Commits

Target	Commit	Files
ext/random	dd54d17	21
ext/uri	7ff9aff	91
ext/intl	e879459	63
ext/phar	d614876	163

Changelog:

• 2026-07-20: added ext/intl and ext/phar
• 2026-07-21: target format \PHP_EOL -> PHP_EOL

---

PoC, marked as draft for now, and in coordination with Tim for now only applied to ext/random and ext/uri.

[NickSdot]

@LamentXU123 I noticed your like and since you own ext/intl and ext/phar I applied the fixers to it and pushed two new commits. Would love your feedback!

Aside: since I didn't built with all extensions ext/intl serves as a good example for non-provable rewrites. In my run listformatter_with_parameters_error.phpt was skipped.

[thg2k]

Is the \PHP_EOF really necessary? I think it just is silly in the tests. Just PHP_EOF should be fine.

[NickSdot]

Is the \PHP_EOF really necessary? I think it just is silly in the tests. Just PHP_EOF should be fine.

Nah. Picked it out of habit. No strong opinion; can adjust to whatever we decide.

[LamentXU123]

I actually think this change is trivial. I don't have strong opinions on this (I am on the fence of this huge code churn) so might need to wait for other's opinion.

[LamentXU123]

nit: any reasons for targeting 8.5?

[NickSdot]

I actually think this change is trivial. I don't have strong opinions on this (I am on the fence of this huge code churn) so might need to wait for other's opinion.

Sometimes not avoidable to move things forward. :) Personally, I think it adds enough value to be justified. Flipping \PHP_EOL to PHP_EOL would decrease churn by a bit. Do you also think it's silly? If yes could pull the trigger on making it PHP_EOL.

nit: any reasons for targeting 8.5?

Nope. Could be anything. Which one you want?

[LamentXU123]

Nope. Could be anything. Which one you want?

Should be targeting master. (hint: convert this to draft when you are changing the base to avoid accidentally request a review from everyone)

[NickSdot]

Nope. Could be anything. Which one you want?

Should be targeting master. (hint: convert this to draft when you are changing the base to avoid accidentally request a review from everyone)

Given that you mentioned code churn, I am wondering if targeting master is the right call? Like, when someone diffs 8.6 against 8.5 this would all be extra in the diff. Why not 8.5 and then upmerge to master? Madee a full run over all tests, merging it up would have only 37 merge conflicts on a total of 2424 affected files. After the upmerge a separate master targeted run would only affect 83 new files. Moderate, no?

[NickSdot]

Changed to PHP_EOL; 37 files less affected; still targets PHP 8.5.

[TimWolla]

I am wondering if targeting master is the right call?

Yes. This is a refactoring, which is not acceptable in released branches.

---

To reduce churn, can the formatter also keep the type of quotes for the colon in cases where the general format is already as expected? The changes in ext/uri provide no value to improve the strength of the actual assertion. Phrased differently: If the change to the test code does not result in a change in the EXPECT section, then drop the change to the test code.

[NickSdot]

I am wondering if targeting master is the right call?

Yes. This is a refactoring, which is not acceptable in released branches.

Will target master! (surprised that this applies to tests)

To reduce churn, can the formatter also keep the type of quotes for the colon in cases where the general format is already as expected? The changes in ext/uri provide no value to improve the strength of the actual assertion. Phrased differently: If the change to the test code does not result in a change in the EXPECT section, then drop the change to the test code.

I evaluated this before. Not worth the extra complexity and inconsistency, IMO. Why: your modules are already so clean that ext/uri is in fact the clear outlier -- 73/104 files are in your ext/uri, only 31 more files that would be affected by what you propose are in all other tests (as in: all phpt, not only in the four modules committed here). Would not start to make things inconsistent or introduce extra rules for that, personally. However, if changing these 104 files (out of 2,369 total) would be an absolute dealbreaker I of course can make one manual commit to revert them. :)

Though, there are other cases like where output is fixed in try/catch that not actually throw. These are risk free to fix, I did so, and I think we should. Why: contributor comes to an existing test file to add test, copies existing test, style is wrong, you review and flag it. You wasted time, contributor wasted time. Or it's missed and merged. Both avoidable. Having one consistency sweep will decrease this "risk". Even code owners have recent PRs that do not follow the regression-safe pattern. When -- after this here would be merged -- everyone sees everywhere the exact same pattern it will naturally be be better adapted. The same would of course be possible if we would make this part of the CI; but you didn't seem very bullish on that?

Assumed we would do what you say, here some stats: 545 total files less; 243 are one lines changes, 334 out of it are <= 2 line diffs, 411 are <= 5 line diffs.