What is this ?

xunit.fixtureinjection is a library to support Integration Testing with xUnit. It does this by providing a set of shims that facilitate Dependency Injection for Collection, Class and Test Case Fixtures.

This framework is DI Container agnostic because it simply provides a set of Factory Method hooks into the xUnit pipeline. For example, I use it with Ninject on a Raspberry Pi to do hardware Integration Tests. The Collection Fixtures handle global shared resources that don't need to be reset between tests, such as access to kernel logs, while Ninject's Named Scopes allow the Class Fixtures to provide deterministic disposal of loaded kernel modules between test classes in a completely transparent manner. But it's just as easy to use it with Autofac or Poor Man's DI.

Why use this ?

While xUnit can be used as a general purpose testing framework, its primary goal is Unit Testing. To leverage it for any meaningful Integration Tests it is necessary to write some boilerplate (which this library does for you) or compromise in some way architecturally. Solutions exist, such as the Service Locator Anti-Pattern or the xunit.ioc package. The former is just hideous and the latter (at this time) only supports xUnit v1.

In a Nutshell

Mark your assembly as requiring injection:

using Xunit.FixtureInjection;

[assembly: RequiresXunitFixtureInjection]

Collection Fixtures as Composition Roots

Create your Collection Definition:

	[CollectionDefinition("MyCollection")]
	public class CollectionFixtureWithInjectionSupportDefinition : ICollectionFixture<CollectionFixtureWithInjectionSupport>
	{
	}

Create your Collection Fixture (with empty constructor or taking an IMessageSink, as per the usual xUnit rules) and mark it with ICreateClassFixtures if you wish to use Class Fixtures, and / or mark it with ICreateTestCaseFixtures if you wish to use Test Case Fixtures. Be sure to use an explicit interface definitions to 'hide' the Service Locator like horridness:

	public class CollectionFixtureWithInjectionSupport : ICreateClassFixtures, ICreateTestCaseFixtures
	{
		TFixture ICreateClassFixtures.CreateClassFixture<TFixture>()
		{
			return ...;
		}

		TFixture ICreateTestCaseFixtures.CreateTestCaseFixture<TFixture>()
		{
			return ...;
		}
	}

Create your Class Fixture or Test Case Fixture with any dependencies it requires:

	public class ClassFixtureRequiringInjection
	{
		public ClassFixtureRequiringInjection(Foo foo, Bar bar, ...)
		{
			...
		}

		...
	}

	public class TestCaseFixtureRequiringInjection
	{
		public TestCaseFixtureRequiringInjection(Foo foo, Bar bar, ...)
		{
			...
		}

		...
	}

Use the Class Fixture or Test Case Fixture in any tests that are part of the Test Collection:

	[Collection("MyCollection")]
	public class ClassFixtureInCollectionWithInjectionSupportTest : IClassFixture<ClassFixtureRequiringInjection>
	{
		public ClassFixtureInCollectionWithInjectionSupportTest(
			ClassFixtureRequiringInjection classFixture,
			TestCaseFixtureRequiringInjection testCaseFixture)
		{
			...
		}

		[Fact]
		public void ExpectXunitFixtureInjectionIsAwesome()
		{
			...
		}
	}

Collection Definitions as Composition Roots

This is the same as above, but the difference is in the way that the Collection Definition is written. Note that the Collection Definition constructor must be empty or take a single IMessageSink argument.

	[CollectionDefinition("MyOtherCollection")]
	public class CollectionFixtureDefinition : ICollectionFixtureRequiringInjection<CollectionFixtureRequiringInjection>
	{
		public CollectionFixtureRequiringInjection CreateCollectionFixture()
		{
			return ...;
		}
	}

The Collection Fixture is then free to request dependencies:

	public class CollectionFixtureRequiringInjection
	{
		public CollectionFixtureRequiringInjection(Foo foo, Bar bar, ...)
		{
			...
		}
	}

The Collection Fixture can also implement ICreateClassFixtures and ICreateTestCaseFixtures if desired.

Simples.

Builds