Notes on .NET Testing Frameworks
When I was introduced to TDD the first testing framework I used was MsTest. Why? Because it was the next best thing available and it had the nice (beginner-) benefit of Visual Studio Integration. Soon after that, when I first hit the limitations of MsTest, MbUnit became my testing framework of choice. At the time I evaluated the existing testing frameworks, I came to the conclusion that MbUnit was the project with the most sophisticated facilities to write tests at all layers (unit, integration, scenarios) and was growing at a remarkable pace.
A year later, at InishTech I started to use xUnit. There are several things about its design that I like better than what I have seen in other testing frameworks so far:
- Classes containing tests can be plain C# classes, no deriving from a base class, no special attributes
- No setup/teardown methods, instead convention based “Fixture” injection (using IUseFixture<T>)
- No useless Assert.x( ) overloads that take custom messages, instead well formatted test output
- Assert.Throws(Func<>) instead of [ExpectedException] attributes. Gives finer grained control over the location an exception is expected.
- Clear, concise terminology. A test is a [Fact], a parameterized test is a [Theory]
To come to a conclusion, I think xUnit is a strong and lightweight testing framework.
MbUnit carries the massive overhead of the Gallio Plattform, making it’s test runner considerably slower than xUnits’. What I do especially like about xUnit is that it is an opinionated framework, it tries to force you into a certain way of thinking and thereby avoid common mistakes. From an extensibility point of view, xUnit has a lot to offer and I find the clear API and the few concepts it is built on compelling. Unfortunately I have no experience extending MbUnit, but extending xUnit is really, really easy.