pytest fixture ref

---

Documentation: https://rtaycher.github.io/pytest-fixture-ref

Source Code: https://github.com/rtaycher/pytest-fixture-ref

PyPI: https://pypi.org/project/pytest-fixture-ref/

---

Let developers reference pytest fixtures without name matching magic.

Pass fixtures via default value or decorator args instead of magic strings.

pytest fetches fixtures by argument name instead of by object references, this breaks python convention and can feel odd/like too much magic. ex:

def test_bar1(fix_w_yield1, fix_w_yield2, tmp_path):
    assert tmp_path.exists()

in regular python code you wouldn't expect this to initialize the variables from fixture functions fix_w_yield1/fix_w_yield2/tmp_path

Let me admit this workaround for pytest fixture reference a bit of a hack. It might be important to note that this still uses pytests usual magic string matching under the covers by grabbing the function name and re-writing the function. That means you do have to make sure pytest imports it by installing it/specifying it in pytest_plugins/etc as well as importing it for reference. It also means this technically works with fake/dummy functions with the same name (in case you can't easily import some fixtures)

example:

from pytest_fixture_ref import using_fixtures_from_defaults, using_fixtures_from_kwargs

@using_fixtures_from_defaults
def test_bar1(_=fix_w_yield1, __=fix_w_yield2, tmp=tmp_path):
    assert tmp.exists()


@using_fixtures_from_kwargs(_=fix_w_yield1, __=fix_w_yield2, tmp=tmp_path)
def test_bar2(_, __, tmp):
    assert tmp.exists()

You can also use it to reference fixtures from other fixtures

@pytest.fixture
def first_entry():
    return "a"


@pytest.fixture
@using_fixtures_from_defaults
def order(fe=first_entry):
    return [fe]

Installation

pip install pytest-fixture-ref

Development

• Clone this repository
• Requirements:
  • Poetry
  • Python 3.7+
• Create a virtual environment and install the dependencies

poetry install

• Activate the virtual environment

poetry shell

Testing

pytest

Documentation

The documentation is automatically generated from the content of the docs directory and from the docstrings of the public signatures of the source code. The documentation is updated and published as a Github project page automatically as part each release.

Releasing

Trigger the Draft release workflow (press Run workflow). This will update the changelog & version and create a GitHub release which is in Draft state.

Find the draft release from the GitHub releases and publish it. When a release is published, it'll trigger release workflow which creates PyPI release and deploys updated documentation.

Pre-commit

Pre-commit hooks run all the auto-formatters (e.g. black, isort), linters (e.g. mypy, flake8), and other quality checks to make sure the changeset is in good shape before a commit/push happens.

You can install the hooks with (runs for each commit):

pre-commit install

Or if you want them to run only for each push:

pre-commit install -t pre-push

Or if you want e.g. want to run all checks manually for all files:

pre-commit run --all-files

---

This project was generated using the wolt-python-package-cookiecutter template.