[Feature] Per-unit and per-class fixture configuration - PR welcome?

[martin-rueegg]

Note: I may not be aware of all configuration options or available functionality, so please let me know if I'm missing something.

AFIK, there is the option to configure fixtures in the test configuration, as well as in the configured fixturesMethod (_fixtures).

In our project, humhub/humhub, we use the fixturesMethod to adjust the configured fixtures from the configuration based on the test case's need. Mainly to speed up tests that do not require db data or just a subset of it.

In some situations, however, it seems to make sense to collect several tests in one case, but only some of them do actually need the fixtures, or some need a different set.

Now we had the idea to use attributes to allow that fixtures to be configured: see examples and current suggested implementation (open for improvement).

The question of this issue is if there is interest that we would incorporate this feature into this project here, potentially in the loadFixtures() method. The logic could be

• If the fixturesMethod is implemented, just use its result
• Otherwise, check for class and test attributes and use their result, if present

If the new functionality is encapsulated in a public method (e.g. getTestFixtures()) and we would pass the yii2 module instance as an argument to the fixturesMethod for easy access, the fixturesMethod could still use that configuration and customize as required. By this, there would be full backwards-compatibility while supporting fixture configuration without the need to implement the fixturesMethod.

The annotations generally allow the following:

• define a default set of fixtures
• use a configuration array to reduce or extend the default set
• on test level, the class level can be overridden, also falling back to the original configuration
• a special class FixturesNone would simply disable any fixtures for the current test.

Thank you for considering this. Any feedback welcome.

Please note, the current code in the aforementioned PR is not designed to meet this project's guidelines. Happy to adapt accordingly if you'd be interested in considering an implementation in your code base.