There have been significant changes in the latest alpha build of xUnit.net. Some of these changes will cause compilation errors for developers upgrading from previous alpha builds (as well as v1).
This release has added support for writing unit tests in several new class library formats: Windows 8 class libraries, Windows Phone 8 class libraries, and Portable Class Libraries that target either of those (plus Desktop .NET 4.5). The runners that we supply can run those tests, although they are currently run in the desktop CLR. Three assemblies have been converted to PCLs as a result: xunit.abstractions.dll, xunit.assert.dll, and xunit.core.dll. The rest of the DLLs remain in their current configuration of supporting either Desktop .NET 3.5 or 4.5.
We've added the ability to control the maximum number of threads used when parallelizing test collection. Within code, you can specify an assembly-level attribute to set this value:
[assembly: CollectionBehavior(MaxParallelThreads = 16)]
In addition, we are planning to support the ability to specify this value dynamically from runners. As of this build, the MSBuild runner <xunit> task has a property named MaxParallelThreads that can set this; in addition, Visual Studio runner 0.99.4 also supports configuring this value in the Tools > Options > xUnit.net settings dialog.
A new attribute, [MemberData], is replacing [PropertyData] and supports getting data from properties, fields, and methods. When pulling data from methods, you can also specify parameters to be sent to the method. The language requirements remain unchanged: the property/field/method must be public and static.
For v2, to support source-based discovery, we have sealed TraitAttribute. With this build, we have enabled the ability to write your own custom trait attributes; in addition, unlike v1, these new trait attributes can contribute 0..n sets of trait name/value pairs. When writing these new trait attributes, you must write a discoverer that allows source-based discovery.
For an example of writing your own trait attribute, please see TraitAttribute and TraitDiscoverer.
In support of the feature described above (to support data from fields or methods), the PropertyData attribute has been renamed to MemberData. In addition, the properties PropertyName and PropertyType have been renamed to MemberName and MemberType, respectively.
When parallelization support was added to xUnit.net, it became clear that accurate timing information was not going to be available when tests were run in parallel. As a result, we have removed the Timeout property from the FactAttribute. Timing information is still available in the XML output, though it will be unreliable if test parallelization is enabled. We will ensure that all of our test runners are capable of dynamically disabling parallelization so that accurate timing information will be available (for example, see xunit.tests.msbuild and how we dynamically set those properties in xunit.msbuild during CI builds).
In order to better support asynchronous testing, we've added new async methods: Assert.ThrowsAsync, Assert.DoesNotThrowAsync, and Record.ExceptionAsync. We have also added special overloads of Assert.Throws, Assert.DoesNotThrow, and Record.Exception that will cause compile time compilation errors when called with asynchronous lambdas. This change was necessary to properly support asynchronous tests without unnnecessarily blocking test threads.
We have also reversed the arguments for the special overloads of Assert.Throws that test for parameter names in ArgumentException and derived types.
In order to support testing for Windows 8/Windows Phone 8/Portable Class Libraries, it was necessary to split apart xunit2.dll into two DLLs: one that test authors link against (xunit.core.dll) and one that's used to run the tests (xunit.execution.dll). Runner authors should continue to use xunit.runner.utility.dll which has been updated to support the DLL split. If authors are using XunitFrontController, then detection of xUnit.net v1 vs. v2 is done automatically for them; however, authors using Xunit2Discoverer directly, please note that the test assembly parameter which previous required a path to xunit2.dll now requires a path to xunit.execution.dll.