How-To's

Unit Testing Receives Major Updates in ReSharper and Rider 2018.3 EAP

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:

Basic inspections about public modifier and expected result

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

Taking special conversions into account

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:

Providing values for parameterized tests in-place

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:

Checking of test cases

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 inconsistent 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:

Fixint test output in Xunit tests

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!

image description