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:
Even special conversions are covered by those inspections, like from
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
Debug.WriteLineIf are not considered at all. However, we are looking forward to hearing about your feedback on whether they should be included somehow.