» Release Notes
» Release Notes
Today we’re shipping three new prereleases:
0.2.0-pre.69 (release notes)1.16.0-pre.223.0.0-pre.20 (release notes)As always, we’d like to thank all the users who contributed to the success of xUnit.net through usage, feedback, and code contributions. 🎉
These release notes are a list of changes from 1.15.0 to 1.16.0-pre.22.
BUG: We have fixed an issue with xUnit1012 giving a false positive when the signature of the method was a nullable params array of a non-nullable type, and the developer passed a single null value to [InlineData]. The developer’s intention here is to pass null for the array (which is legal, and works at runtime), but the analyzer was incorrectly flagging this as an incompatible params value. xunit/xunit#2973
We have updated xUnit1041 for v3 users to support the new [Collection(typeof(T))] and [Collection<T>] attribute overloads.
We have created xUnit1051 to call out cases in v3 unit tests where the developer could be passing a cancellation token but isn’t. The recommended cancellation token is the one from TestContext.Current.CancellationToken, though passing any cancellation token will satisfy the analyzer.
The logic for determining when the user could pass a cancellation token is that either (a) the method they’re calling has an optional CancellationToken parameter, and they’re not passing one, or (b) there is an otherwise identical overload of the method they’re calling that includes, as the only extra parameter, a CancellationToken. This catches the vast majority of situations, but it is good for developers using v3 to become accustomed to passing the cancellation token whenever possible, including choosing overloads that allow cancellation over ones that don’t (even if that means choosing a slightly different overload, like choosing an async variant over a synchronous one).
We have created xUnit2030 to suggest that users can convert code like this
Assert.NotEmpty(collection.Where(item => /* ... */));
to this form, which provides better output when the test fails:
Assert.Contains(collection, item => /* ... */);
We have updated xUnit3001 to verify that any class which is decorated with [JsonTypeID] has a parameterless constructor for deserialization purposes.
We have created xUnit3002 to flag usages of the concrete message types instead of their interface variants. (Note: the rule currently has a bug where it has some false positives, so it’s set to Hidden right now until we can resolve this issue. If you enable the rule, please be aware that these false positives are possible.)
Async to their name is not necessary for usability (and impacts their display name). xunit/xunit#2978