Continuous Testing in dotCover and ReSharper Ultimate
Warning: This post is outdated. Continuous testing UX has been reworked. Find the up-to-date instructions in the dotCover documentation.
Over the last couple of years, continuous testing has been the top anticipated dotCover feature. Now, the wait is finally over as dotCover 10 supports continuous testing in Visual Studio! Before we move on to the nitty-gritty details to show you how it works, let’s try to recall what continuous testing actually is.
In a nutshell, continuous testing means testing ‘without interruption.’ It implies that tests are run in the background, so you have actual test results instantly, as soon as you’ve changed your code. This dramatically speeds up a developer’s workflow as there’s no need to manually rebuild the project and re-run all tests after making changes: the impacted tests are run in the background automatically (the testing session is triggered by some explicit action, e.g., saving changes).
If you practice test-driven development, the benefit is even more pronounced: the Red-Green-Refactor workflow becomes virtually seamless. All the boring routines go away, leaving you only with the fun part:
1. Write a test.
2. Write a stub.
4. Run the tests (they must fail).
5. Update the stub to return the expected result.
7. Run the tests (they must pass).
8. Write the code.
10. Run the tests (they must pass).
11. Refactor the code.
13. Run the tests (they must pass).
So, how to use continuous testing in dotCover? It’s very easy, with only three steps to follow.
1. Open Continuous Testing Session window
Continuous testing is managed via the Continuous Testing Session window. To open it, use the menu ReSharper | Unit Tests | Show Continuous Testing Session.
2. Select continuous testing mode
By default, continuous testing is switched off. To make it work, select one of the modes in Mode:
A wide variety of combinations are available. For example, you can tell dotCover to automatically build and run dirty tests after you save the project. Or, run dirty tests only after you build the project.
What does ‘dirty test’ mean? It is the test that was impacted by code changes. For example, you have a test that covers some code, you change the code, and the test result is now obsolete, i.e. the test becomes ‘dirty.’ In addition, dotCover considers as ‘dirty’ all new tests, tests that were aborted by user (aborted), and tests that failed to complete for some reason (inconclusive).
3. Just work
Once continuous testing is enabled, you can simply start working. Initially dotCover will mark all tests as dirty.
The current tests status can be checked on the continuous testing icon in the status bar (bottom right corner of the main Visual Studio window). This handy assistant shows you whether there are any failed tests or all of them pass successfully. The Continuous Testing Session window displays the results in more detail:
As we already mentioned, your workflow with the enabled continuous testing is almost seamless. Suppose you change code that is covered by some tests and save the project (and you’ve selected the On ‘Save’ Build and Run Dirty Tests mode). dotCover builds the project and re-runs (only) dirty tests in the background:
To navigate to a failed test, click the test in Continuous Testing Session window or click the number next to the continuous testing icon.
Another option to navigate to the covering tests is to do it right from the code. Simply click on the code and select Show covering tests in the context menu. This opens the list of all tests that cover this line of code. Here you navigate to the corresponding tests or force them to run:
If you’re willing to try continuous testing right now, download and install ReSharper Ultimate.
IMPORTANT! If your tests that use external files fail during continuous testing (while being successful in a traditional unit testing session), you should properly set dotCover’s Shadow-Copy option. The following post describes in details how this option works.
Should you have any questions, please feel free to ask in the comments to this post. Your feedback is greatly appreciated!
Subscribe to Blog updates
Thanks, we've got you!
Another Look into the Future with Rider’s Predictive Debugger
In the 2023.2 release cycle, we’ve introduced the Predictive Debugger in ReSharper, which gives you predictions about code paths and variables beyond the current execution pointer. We’ve written extensively about its advantages compared to alternative debugging strategies like thorough thinking, log…
Visualize Entity Framework Relationships and Additional Query Analysis in ReSharper 2023.3
A lot of teams are using Entity Framework or EF Core to work with their database. As an Object-Relational Mapper (ORM), it bridges objects in code to a relational database model, so that as a developer you don’t have to worry too much about the actual database. We all know: that’s not entirely tr…
Automatically Analyze ASP.NET Core Performance With Dynamic Program Analysis
Slow web pages may make your users or customers abandon your web application, even before they’ve had a proper look at it. You’ve likely also been frustrated working with a web application that is slow to load. The good news is that the latest versions of ReSharper and JetBrains Rider’s Dynamic P…
OSS Power-Ups: MassTransit – Webinar Recording
The recording of our webinar, OSS Power-Ups: MassTransit, with Chris Patterson, is available. This was the thirteenth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webinars.…