Markus Staab

> Isn't it solving that need already ? thanks, wasn't aware of `--fail-on-empty-test-suite`. I think the behaviour of `--fail-on-empty-test-suite` should be the default for `--filter` (or maybe even in general).

thanks for the examples. that indeed proves that my initial problem is actually not the same as the feature `--fail-on-empty-test-suite` seems to provide. I think its a DX problem that...

So this is a alternative to putting mutators into levels, right? Having levels and weights at the same time would be confusing I think.

in the discussion in https://github.com/infection/infection/pull/2238#discussion_r2158376677 we talked about doing less-assumptions in a mutator based on the level. if we use weights instead we need to think about how we want...

hmm. maybe we need the weight on the mutation, not the mutator? a single mutator can emit different mutations of different weight (based e.g. one on assumption has different weight...

> * disallow to repeat a test which is dependent of another one which returns something IMO this sounds good. I would additionally emit a PHPUnit warning in such case.

yes, atm a few spurious errors are in CI. these here are related though: https://github.com/phpstan/phpstan-src/actions/runs/18773626957/job/53563151392?pr=4474

Looking at `tests/end-to-end/execution-order/order-by-defects-test-classes-with-defects.phpt`, I wonder why the expectation is that after the 2 failled tests namely `testThree` and `testTwo` - the 2 succeeding tests are expected in the order `testFour`,...

One PR I remember related to sorting is https://github.com/sebastianbergmann/phpunit/pull/6263 which landed in PHPUnit 11.5+, which means at least for cases which use data-provider there might be a difference between PHPUnit...

Huhu. I guess it would be easier for us to have a single mutator class and integrate it with the [to be defined feature toggle](https://github.com/infection/infection/issues/2312). When implemented in separate mutators...