site/releases/analyzers/1.16.0.md
Today, we're shipping one new release and two new prereleases:
0.3.0-pre.18 (release notes)1.16.03.0.0-pre.30 (release notes)It's been 8 weeks since the release of 1.15.0.
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 1.15.0 to 1.16.0.
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{: .issue-link }
BUG: We have fixed an issue with xUnit1012 giving a false positive when the user provides compiler-prohibit data values to [InlineData] (i.e., decimal values). The compiler will still flag the usage with CS0182 as appropriate. xunit/xunit#3000{: .issue-link }
BUG: We have fixed an issue with xUnit1039 giving a false positive when matching data types against a collection of an open generic type in the test method (i.e., T[] or IEnumerable<T>). xunit/xunit#3007{: .issue-link }
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 added a fixer which will either add TestContext.Current.CancellationToken or convert explicit usages of default or default(CancellationToken) into TestContext.Current.CancellationToken.
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 added a fixer for xUnit2031 that will convert the LINQ Where clause into the two-argument Assert.Single call instead.
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 Core Framework v3 concrete test message types instead of their interface variants.
Async to their name is not necessary for usability (and impacts their display name). xunit/xunit#2978{: .issue-link }