Unit Testing Receives Major Updates in ReSharper and Rider 2018.3 EAP

Matthias Koch

Is TDD dead? That very provocative talk between Martin Fowler, Kent Beck, and David Heinemeier Hansson dates back to 2014. Unit testing integration hasn’t seen any notable improvements since then, but we’re about to change that with the upcoming ReSharper and Rider 2018.3 release. New inspections, context actions, and quick-fixes will help us write NUnit and xUnit.net tests in a breeze; with more confidence and more flexibility. Let’s have a look!

Starting with basics

Have you ever been in a situation where your tests were not discovered, even though you’ve marked them with the TestAttribute? NUnit requires test methods to be public, to be discovered, which is now shown as an inspection.

Another little tweak is that the actual return type is checked against the value provided via ExpectedResult. Some of those can easily be corrected with a quick-fix:

Even special conversions are covered by those inspections, like from string to DateTime or int to byte:

Those are just a few of several additions that made it to this new release. Testing really is an important discipline in software development, so let’s dive a little deeper.

Parameterizing tests in NUnit

Sometimes it is desirable to verify our code against a large set of input values. NUnit allows doing that using a rich set of attributes that are applied on method and parameter level. For combinatorial, sequential, and pairwise tests, values can be provided in place as concrete values, random values, or range values. ReSharper and Rider can help us do this very quickly with the Provide values context action:

NUnit also allows using the TestCaseAttribute to define test cases both locally and explicitly. Whenever appropriate, ReSharper and Rider will give a warning when test cases aren’t complying with the number of values or their types:

Note, that even async tests are correctly recognized and checked against their actual return type.

Whenever the number of test cases grows too large, NUnit provides another mechanism through the TestCaseSourceAttribute, where values can be provided by sources. These sources can be implemented as custom types deriving from IEnumerable, as static IEnumerable methods/properties/fields, or as custom types declaring such. With 2018.3, we added inspections and quick-fixes to ensure consistent test source declarations:

Fixing test output in xUnit.net

Another great improvement is the following inspection that warns us about Console.WriteLine usages in xUnit test code, since they’re not getting printed in the output. The related quick-fix will redirect the call to an instance of ITestOutputHelper, which is an Xunit abstraction. If necessary, a readonly field will be introduced and initialized from the constructor:

Note that the functionality of this inspection/quick-fix is limited. Because of the current implementation of ITestOutputHelper, a call to Console.Write can’t be automatically fixed. Also similar invocations like Trace.WriteLine or Debug.WriteLineIf are not considered at all. However, we are looking forward to hearing about your feedback on whether they should be included somehow.

Download ReSharper 2018.3 EAP now! Or give Rider 2018.3 EAP – our cross-platform IDE – a try! We’d love to hear your feedback!

Subscribe to a monthly digest curated from the .NET Tools blog:

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!