Oliver Klee

Let's get this in before the 9.0 release.

When we implement the trait, we don't need to add it to the `@covers` annotations of the corresponding testcases as PHPUnit [includes them automatically starting with version 7.3](https://github.com/sebastianbergmann/phpunit/commit/7372585bdc9a4cc1f710d5d447babd30c7b8072e).

Yes, that's the way to go. (We'll need to check whether we can `@covers` a trait directly, though. [PHPUnit 12 has the `CoversTrait` attribute](https://docs.phpunit.de/en/12.0/attributes.html), which we can't use in PHPUnit...

Two more thoughts on this: - There is no way to test that a class actually uses a trait. So while we might have dedicated tests for a trait, this...

> Do you mean "... fan of adding traits only if there ..."? Oh, yes, of course. Thanks for noticing and asking!

I'd be fine with either `getObjectForTrait` or a fixture class in `tests` that uses the trait. (I'd slightly prefer the latter.) Edit: And I'd prefer a "real" fixture class over...

Thanks for reporting this! This seems to be a missing feature. I've tagged and renamed this issue accordingly.

> `RuleSetItem`? I like that. (And it should definitely be an interface, not a class.) > `RuleSet::parseRuleSet()` would need an extra Boolean parameter to permit declaration blocks as well as...

This is the code smell/antipattern I was referring to: https://luzkan.github.io/smells/flag-argument

Maybe we might put this on the back-burner and tackle this after [a rewrite](#1189).