It has been approximately 2 weeks since we released v2 Core Framework 2.5.3 RTM.
As always, we'd like to thank all the users who contributed to the success of xUnit.net through usage, feedback, and code. 🎉
These release notes are a comprehensive list of changes from 2.5.3 to 2.6.0.
[InlineData]where the current locale is one which uses Unicode U+2212 as the minus sign for integers rather than Unicode U+002D, which caused
Enum.Parseto fail. Additionally we have opened an issue against .NET to try to get a "known safe to roundtrip" value from
Enum.ToString()that would make this workaround unnecessary, as all overloads of
Enum.ToString()that take format providers (aka cultures) are marked as obsolete and the format provider is ignored. xunit/xunit#2796 dotnet/runtime#93663
xunit.assert, along with the existing
netstandard1.1target. This new target enables assertion overloads that support
Memory<T>(and their read-only counterparts), overloads that support
ValueTask<T>for asynchronous operations (in places where we already supported
Task<T>), and overloads that support
ImmutableDictionary. Developers whose test projects target .NET 6 (or later) will automatically get access to these new assertion methods. Note that this may introduce new compiler ambiguities due to the additional overloads; for more information, see issue 2793.
ValueTasksupport only applies to the assertion library. Test methods must return either
voidif they are async;
ValueTaskis not supported in this scenario until v3.
Assert.Equalsto catch when exceptions are thrown when calling a user-defined comparer (either a comparer function, or an implementation of
IEqualityComparer<T>). Previously this would just surface as the exception being the cause of the failure; now it will show an
Assert.Equal() Failuremessage (which includes the collection including a pointer into the collection, when the thing being compared is an item in a collection) as well as the exception that was thrown. This should greatly help in debugging user-provided comparison functions to understand which data item caused the exception. xunit/xunit#2800
KeyValuePair<TKey, TValue>when using
Assert.Equal(including when what you're comparing is a collection of key/value pairs). We already had special handling for dictionaries with special equality handling for the key and the value; this extends that behavior to the "dictionary-like" situation of
IEnumerable<KeyValuePair<>>as well. xunit/xunit#2803
NotImplementedException, causing some code paths for
Assert.Equalto throw when the hash code was needed. xunit/xunit#2804
Assert.Equalwith collections. In some situations, the comparison could take as much as 10x (1000%) longer as in 2.4.2. Most of the performance issues have been resolved, and the new collection assertion is within 10% of the older assertions (and in some cases on .NET 6+, the new collection comparison can be a few orders of magnitude faster, for arrays of unmanaged values). xunit/xunit#2806