Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IAssemblyFixture should be part of xUnit #1947

Closed
D0tNet4Fun opened this issue May 21, 2019 · 3 comments
Closed

IAssemblyFixture should be part of xUnit #1947

D0tNet4Fun opened this issue May 21, 2019 · 3 comments

Comments

@D0tNet4Fun
Copy link

IMHO assembly-level fixtures should be officially included in xUnit. Here's why:

In order to implement this behavior outside of xUnit, one has to override the XunitTestAssemblyRunner and then inject this custom test assembly runner into a custom test framework that overrides the xUnit test framework just enough to add the custom behavior. This is the case with https://github.com/kzu/xunit.assemblyfixture. This approach requires a full-blown test framework to be used in the test project. There are several custom test frameworks available out there, each one with its unique features. I.e. as a end-user I would like to order my test cases using https://github.com/tomaszeman/Xunit.Extensions.Ordering and also use the assembly fixture defined by @kzu . I can't do so because my test project can use only one test framework - which makes sense from a technical perspective. Fortunately @tomaszeman added this behavior to his framework, although it might not have been needed for ordering test cases (I suppose).

The way it looks to me, every test framework author has to add this behavior if their users request it. This could be an indication that this should not be regarded as an extension, but as core functionality that is currently missing from the xUnit framework. If you agree to this then I suggest this behavior:

  • add new type IAssemblyFixture<> that works similar to IClassFixture<> but at a higher scope (the test assembly)
  • design for extensibility to allow the test framework authors extend the functionality
@fairking
Copy link

fairking commented Aug 20, 2020

I cannot do certain things with xunit. Eg. pass the config parameters to the base reference before any test starts. I was trying different things like ModuleInit but it runs after the first base fixture starts:
For example:
MyApp.Core.Tests:

public class ServicesFixture : IDisposable
{
        public static Assembly[] Assemblies = new[] { typeof(CoreClass).Assembly };
        private readonly IServiceProvider _services;

        public ServicesFixture()
        {
            _services = new StandardServiceBuilder(Assemblies).ConfigureServices();
        }

        public IServiceProvider Services { get { return _services; } }

        public void Dispose()
        {
            if (_services is IDisposable)
                (_services as IDisposable).Dispose();
        }
}

MyApp.Module1.Tests: (has a reference to MyApp.Core.Tests)

// Somewhere in the code
ServicesFixture.Assemblies = new[] { typeof(CoreClass).Assembly, typeof(Module1Class).Assembly };

For this approach I would like to have some ability to execute a command before any test starts.

Please add a global fixture and teardown. It is easy to do I assume as many people do that by overriding the XunitTestAssemblyRunner.

@fjmorel
Copy link
Contributor

fjmorel commented Sep 16, 2021

I would love something like this. We currently use a CollectionFixture to start a Mongo server (using the amazing Mongo2Go library) for the majority of our tests, but are using randomized collection names for each test to avoid having to clean up between each test. Since they can't conflict with each other, I would like to not prevent them from running in parallel and remove the collection definition.

edit: maybe [ModuleInitializer] would be a good workaround in some cases, but doesn't cover disposing.

@bradwilson
Copy link
Member

The implementation I landed on is different from kzu's. It is dependent on an assembly-level attribute to specify the assembly fixture:

[assembly: AssemblyFixture(typeof(MyFixture))]

Composition rules have been updated:

  • Class fixtures can compose collection and assembly fixtures (accepted via ctor argument)
  • Collection fixtures can compose assembly fixtures (accepted via ctor argument)

In addition, I added support for ctor arguments in all three fixtures for ITestContextAccessor (in addition to _IMessageSink for the diagnostic message sink).

I will update the online documentation soon to reflect all of this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants