Problem
On ServiceListDelegateTest (extends SiControllerTestCase, hits the test DB), the post-edit phpunit-mcp validator reported 2 failures ("Looking for Table in response… <div…>") — and rector-mcp reported "Call to a member function toMutatingScope() on null". The validators even self-labeled them "pre-existing — not from this edit".
The real phpunit: op on the same file passed cleanly (3/3, 173 assertions). So the mcp runner produced false reds — almost certainly running without the same test-DB/autoload bootstrap the real op uses.
Why it matters
A validator that cries wolf erodes trust in its greens too. After this I had to re-run the real runner to know the truth, which defeats the point of the inline validator.
Suggestion
- Give the mcp test/rector runner the same env (test DB, autoload cache) as the standalone
phpunit:/rector: ops, OR
- Detect
SiControllerTestCase / DB-backed tests and defer to the real runner instead of the warm mcp path, OR
- At minimum, suppress results the runner itself classifies as "pre-existing / not from this edit" so they don't read as failures of my change.
Problem
On
ServiceListDelegateTest(extendsSiControllerTestCase, hits the test DB), the post-editphpunit-mcpvalidator reported 2 failures ("Looking for Table in response… <div…>") — andrector-mcpreported "Call to a member function toMutatingScope() on null". The validators even self-labeled them "pre-existing — not from this edit".The real
phpunit:op on the same file passed cleanly (3/3, 173 assertions). So the mcp runner produced false reds — almost certainly running without the same test-DB/autoload bootstrap the real op uses.Why it matters
A validator that cries wolf erodes trust in its greens too. After this I had to re-run the real runner to know the truth, which defeats the point of the inline validator.
Suggestion
phpunit:/rector:ops, ORSiControllerTestCase/ DB-backed tests and defer to the real runner instead of the warm mcp path, OR