Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#92 18 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
php
Domain
testing

Research direction

Start at src/Codeception/Module/Yii2.php and inspect loadFixtures(), then review the linked examples and suggested implementation. Confirm the project’s desired API for class and test attributes and its compatibility with fixturesMethod; done means the fixture defaults, overrides, and disabling behavior are agreed and covered.

Written by the indexing model from the issue text.

Description

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.

Dominant language
PHP
Stars
19
Forks
42
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Codeception/module-yii2

All issues in Codeception/module-yii2

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.