Why you should consider using xUnit

Recently I have been using the xUnit Testing framework and I would like to share few of its nice features with you. It is simple, easily extensible and aligned with practices such as TDD (Test Driven Development) and BDD (Behaviour Driven Development).

Test attributes

xUnit does not require an attribute for a test class. It looks for all test methods in all public classes in the assembly. The [Fact] attribute defines whether the public method should be included as a Test method or not.

If you are already familiar with NUnit or MBUnit, you probably know the [Setup] attribute. If you use MSTest then you also probably know the [TestInitialize] attribute. These attributes allow you to specify the code to be run before executing each test. xUnit doesn’t have this attribute and you can simply use the  parameterless constructor as a direct replacement.

Similarly, xUnit does not specify attributes such as [TestCleanup] or [Teadown], and instead you would use the IDisposable.Dipose() method to clean up the resource(s) when required.

Personally, I see this as a much cleaner way to write Unit Tests since there is less code, less maintenance therefore less refactoring.

From xUnit team…

 “The xUnit.net team feels that per-test setup and teardown creates difficult-to-follow and debug testing code, often causing unnecessary code to run before every single test is run.

Ignore Tests

One of the nice features of xUnit is that the [Skip] attribute also accepts an argument so you can specify the reason for your exclusion for the test method. All other major Unit Testing frameworks allow you to use an [Ignore] attribute, but you cannot specify the reason of why it has been ignored/skipped. 

[Fact(Skip = "This test require refactoring.")]
public void AssertAreEqual()
//Your test goes here.


Most xUnit Assert methods don’t have the message as an argument to the Assert methods. xUnit team believes the Asserts API should be descriptive enough except the True/False Asserts. For example Assert.Equal(“Pat”, value, “Value should have been Pat”) doesn’t add much value.


Data driven or parameterized Unit Tests

xUnit also supports data driven and parameterized Unit Tests. For example you can configure your test inputs within the attribute and specify them as an argument to your test method. You can specify parameters to be injected to the test method by specifying the [Theory] and [InlineData]. xUnit support variety of data providers including [ExcelData],  [SqlServerData], and [OleDbData].

[InlineData("hello", 5)]
public void TestTraditional(string value, int expectedLength)
    Assert.Equal(expectedLength, value.Length);

Please note that you must use the xunit.extensions.dll  in order to use data driven or parameterized Unit Tests.


Extending xUnit framework

One of the great things about using xUnit is that it is heavily extensible. You may extend the Test Class, Test Method, or even Asserts. Below is an example of how you would create a Trace attribute to trace your Unit Tests.

 public class BeforeAfterTests
     [Fact, Tracing]
     public void AssertAreEqual()
         Console.WriteLine("I'm inside the test!");

public class TracingAttribute : BeforeAfterTestAttribute
     public override void Before(MethodInfo methodUnderTest)
        Console.WriteLine("Before : {0}.{1}", methodUnderTest.DeclaringType.FullName, methodUnderTest.Name);

     public override void After(MethodInfo methodUnderTest)
         Console.WriteLine("After : {0}.{1}", methodUnderTest.DeclaringType.FullName, methodUnderTest.Name);


VS Integration

For a better VS.Net integration there are some other test runners you can use.  You may use TestDriven.NET, or Telerik’s Just Code Unit Test runner within Visual Studio to run xUnit Test methods. If you are ReSharper user – xUnitContrib project has plugin you can use for ReSharper support.


If you are TDD developer and would love to experiment and extend Unit Tests, I would certainly recommend that you should try xUnit. The attribute names can be unfamiliar in the first go, but the amount of benefits you get here is quite noticeable comparing to other testing frameworks.  Developing your application and writing Unit Test at the same time is not easy as sometimes you need to ensure you save time by reducing unwanted code and spending less time for debugging and refactoring tasks. xUnit provides a nice way to overcome these issues and I highly recommend it.

Below are some links to get you started with xUnit.

Download xUnit


Download xUnit contrib


Integrating xUnit to Team Build process