I checked the fixes against what assertEmpty() does at runtime, at head e7037550f. make tests and make phpstan pass. In five cases the fixed assertion behaves differently from the original. I ran each original and fixed line with real PHPUnit 9.6:

1. The type comes from $scope->getType(), so a PHPDoc type decides the fix. In a test, the assertion is often what checks that the PHPDoc is right. The negated fixes then accept values that the original rejected (the first two rows). $scope->getNativeType() would avoid that. The non-falsy-string case would then not be fixed at all, but assertEmpty() on a non-falsy string can never pass anyway.

2. An empty SimpleXMLElement is empty for empty(), so assertNull() is not the same. ?object has the same problem, because the object can be a SimpleXMLElement at runtime. Fixing only when (new ObjectType(\SimpleXMLElement::class))->isSuperTypeOf(...) is no() for the type without null would keep ?\stdClass and skip both.

3. The rule reads getArgs()[0] as the asserted value and keeps the arguments as they are:

   • With actual: as a named argument, assertFalse(), assertTrue(), assertCount() and assertNotCount() throw an Error, because their parameter is $condition or $haystack. assertSame(), assertNotSame(), assertNull() and assertNotNull() have $actual, so they work.
   • With message: first, the message string is treated as the asserted value, and the fix becomes assertSame('', ...).

   Skipping the fix when any argument is named would cover both.

The other fixes are equivalent for their types, including the extra message argument (assertCount(0, $array, 'message')). float, plain string and unions without null stay unfixed, as the description says.

The three Mutation Testing reds come from this PR. Infection reports 4 escaped mutants, which change ->yes() to !->no() on the isObject(), isBoolean(), isArray() and isInteger() checks. So the tests have no value for which one of these checks is a "maybe" and the fix must not apply. The other CI checks pass.

I only checked the parameter names in PHPUnit 9.6, not in 10 to 12.

I checked b207aedaf again. The PHPDoc, SimpleXMLElement, named-argument and mutation points from my first review are fixed, and the tests, PHPStan and CI pass.

The nullable-object fix still changes results. assertEmpty() also treats an EmptyIterator and a Countable with a count of 0 as empty. isBuiltin() only looks at the declared class, and a subclass or an implementation can add either. I ran the rule's fix on these parameter types and then ran each original and fixed line with PHPUnit 9.6:

Only the final class gives the same result. So the null fix could apply only when each class is final, does not implement Countable, and has no builtin parent. That covers EmptyIterator, ArrayObject and SimpleXMLElement subclasses too.

Copilot's UserDefinedObject|int|null case does not reproduce. The rule leaves Foo|int|null as it is, because getObjectClassReflections() returns nothing when a union member is not an object.

I ran the cases with PHPUnit 9.6 only. The IsEmpty constraint has the same EmptyIterator and Countable checks in 10.5, 11.5 and 12.0.

I checked 89814b5d2 again, and the null fix now only rewrites cases that behave the same at runtime.

I ran the rule's fix on 13 nullable parameter types. It rewrites four of them to assertNull() or assertNotNull(): ?FinalFoo in both directions, FinalFoo|FinalBar|null and a nullable plain enum. I ran each original and fixed assertion with PHPUnit 9.6 against null, both final classes and the enum case. All results are the same.

It leaves the other nine unchanged:

• a final child of a user Countable class
• a final grandchild of ArrayObject
• a final SimpleXMLElement child
• a class that is final only through @final
• a Countable enum
• an interface
• FinalFoo|int|null, FinalFoo|false|null and FinalFoo|string|null

The last three are the nullable unions with scalar members from Copilot's last overview, so that case does not occur. The first two are not in the test data, but the parent loop and implementsInterface() handle them.

The tests and PHPStan pass, and all CI checks are green. Performance: on the PR's three test data files with the rule enabled, both sides report 46 errors. Base took 0.90-0.96 s and this PR 0.95-0.97 s over 5 interleaved runs, which is within noise.