Why Did we Build xUnit 1.0?

This originally appeared on Jim’s blog, and has been updated for the 1.0 release of xUnit.net.

In the 5 years since the release of NUnit 2.0, there have been millions of lines of code written using the various unit testing frameworks for .NET. About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about “do X” or “don’t do Y”, it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.

Additionally, the .NET framework itself has evolved a lot since its v1 release in early 2002. Being able to leverage some of the new framework features can help us write clearer tests.

Another aspect of change that we wanted to affect was bringing the testing framework more closely in line with the .NET platform. Many of the decisions we made, which we enumerate below, were driven by this desire. We wanted an architecture which is built for programmer testing (specifically Test-Driven Development), but can also be very easily extended to support other kinds of testing (like automated acceptance tests).

Finally, there have been advances in other unit test library implementations that have not really surfaced in the .NET community.

While any one of these reasons would not necessarily have been sufficient to create a new testing framework, the combination of them all made us want to undertake a new project: xUnit.net.

Lessons Learned

Language Features

Test Runners

For 1.0, we are shipping several runners:

Extensibility

We also provide a more complete comparison of xUnit.net to other predominant test frameworks on .NET. The samples include illustrations of several key concepts, especially with extensibility.

Copyright © 2017 .NET Foundation. Contributions welcomed at https://github.com/xunit/xunit.github.io.