Please consider adding modular fixtures in v3 roadmap

[MichaelLogutov]

Hello. Being long time user of xunit I can't help to see how limiting current fixtures are in xunit.
This became especially important in later years with the rise of docker which allowed easy integration isolation testing where fixtures playing crucial role.

The main issues in current fixtures implementation in xunit are:

• It's very verbose. To be able to write a fixture that runs only once for test session I need to write separate CollectionDefinition. Can we just create a class, throw some Fixture(Scope="session") attribute on it and have xunit testing framework to find, register it and manage it's instance lifecycle? That would be so much easier.
• It's cumbersome to use. I need mark tests with collection attribute and add fixture to constructor. Again - can we just add new test method parameter of needed fixture class type and having xunit to inject fixture instance automatically?
• It's impossible to use any type of hierarchy in fixtures. If I need two fixtures to depend on other singleton fixture (like db) - i'm out of luck because apparently fixtures can not be injected with other fixtures instances. Would be nice to just declare dependencies in fixture class constructor and have xunit to wire up all instances during initialization like IoC containers do.

Those aren't mine ideas of course. It's from pytest (and pytest took that from other testing frameworks if I'm not mistaken). Just look how simple it is.

You want fixture that runs only once per test session? No problem - just declare it somewhere and test framework will find it and will handle life scope management for you:

@pytest.fixture(scope="session")
def smtp():
    return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)

And you want to use it in particular test method? No problem - just add it to method parameter - test framework automatically injects instance for you:

def test_send_email(smtp):
   smtp.ehlo()

And if you need to use some fixture inside other fixture - that's right, just add it as new parameter and test framework will do everything else:

@pytest.fixture(scope="session")
def some_other_fixture():
    return some_other_fixture_instance()

@pytest.fixture(scope="session")
def smtp(some_other_fixture):
    some_other_fixture.do_something()
    return smtplib.SMTP("smtp.gmail.com", 587, timeout=5)

There are a lot more in pytest fixtures that xunit can implement too. But please consider at least adding a simple way to declare and use fixtures - without CollectionDefinition and constructor injection.

[bradwilson]

* It's very verbose. To be able to write a fixture that runs only once for test session I need to write separate CollectionDefinition. Can we just create a class, throw some `Fixture(Scope="session")` attribute on it and have xunit testing framework to find, register it and manage it's instance lifecycle? That would be so much easier.

I don't understand this scope concept you've introduced here. What's a "session"?

* It's cumbersome to use. I need mark tests with collection attribute and add fixture to constructor. Again - can we just add new test method parameter of needed fixture class type and having xunit to inject fixture instance automatically?

Is your suggestion that you would decorate the fixture class with the fixture type? Because I'm not a fan of that. That's the wrong place for that information to live. How would you create a fixture that has generalized re-use, but is used in various ways (sometimes class fixture, sometimes collection fixture)?

Given that this feature exists today as-is, I'd really like to see more public feedback before flipping the model on its head in a way that would break existing users (both their code and their notion of how the feature is supposed to work).

* It's impossible to use any type of hierarchy in fixtures. If I need two fixtures to depend on other singleton fixture (like db) - i'm out of luck because apparently fixtures can not be injected with other fixtures instances. Would be nice to just declare dependencies in fixture class constructor and have xunit to wire up all instances during initialization like IoC containers do.

There is a generalized IoC feature request in the 3.0 pipeline. Might be worth pointing out on that issue what you're looking for: #1738

[MichaelLogutov]

I don't understand this scope concept you've introduced here. What's a "session"?
Test run session - basically, once per test application.

Is your suggestion that you would decorate the fixture class with the fixture type? Because I'm not a fan of that. That's the wrong place for that information to live. How would you create a fixture that has generalized re-use, but is used in various ways (sometimes class fixture, sometimes collection fixture)?
Do we even need such fixtures? Because I can't imagine writing fixture for per session use and be able to use it like per class.

In any case, maybe we can use both models?

[bradwilson]

(Please reply to existing posts rather than creating new posts. Thanks!)

I don't understand this scope concept you've introduced here. What's a "session"?

Test run session - basically, once per test application.

That will be covered in v3 by assembly level fixtures.

[edouardberthe]

Hi @MichaelLogutov,

I cannot agree with you more. Honestly I do not understand how it is possible that people developping / using xUnit does not see how much the fixtures dependency addition (the fact that a fixture A may depend on a fixture B and that the test framework automatically generate the test cases, etc.) is making by itself pytest litterally most powerful than xUnit.

The boilerplate required to write a test is far too high. Also, indeed, the fact that the syntax is totally different for what xUnit calls "Class Fixture" (implenting an interface) vs "CollectionFixture" (this time a tag with a string as name + a new empty class?) is extremely weird.

The "official" way of combining fixture in xUnit is by making manually another class aggregating the 2 fixtures... how insane is that.
So if you have FixtureA and you want to create a FixtureB whose value depend on FixtureA then you actually need to create FixtureAandB. Then FixtureC, you need FixtureAandBandC....

[MichaelLogutov]

Yeah... For now I've ended up using Xunit.DependencyInjection package. It still a bit clunky since I have to resort to block on async when initializing fixture classes in constructor, but it's a lot cleaner than trying to use native Xunit fixtures.