What’s New in dotCover 2019.3

In 2019’s last release, dotCover is about to receive its fair share of upgrades:

  • Support for Unity tests in JetBrains Rider.
  • Support for Microsoft Fakes in Visual Studio 2017 or later.
  • The ability to group coverage results by nested namespaces in both Rider and Visual Studio, and in reports generated by the dotCover console tool.

Let’s check out the details!

Unity support

Adding support for Unity tests was the main focus of the 2019.3 release. Here are the highlights:

  • Support for coverage analysis in Unity projects is available only in JetBrains Rider.
  • To run coverage analysis, your Unity project must have the Rider Editor and Test Framework packages. Version requirements:
    Unity Rider Editor Test Framework
    2018.3 – 2019.1 any any
    2019.2 and later 1.2.0 or later any
    Earlier than 1.2.0 1.1.1 – 1.1.3

    Note: To be able to run tests, make sure your project has Test Framework 1.1.1 or later.

  • To run coverage analysis, Unity Editor must be started in the special mode with coverage support enabled.
  • Only edit mode tests are supported.

The workflow is as follows:

  1. Open your Unity solution in Rider.
  2. On the Unity toolbar, choose Start Unity with Coverage:
    Start Unity Editor with Coverage
    This will run Unity Editor with coverage support enabled (your Unity project will be opened automatically).
  3. In Rider, open the Unit Tests window, select the desired tests, and click the Cover Selected Unit Tests button.
    dotCover. Cover Unity Tests
    This will run the tests with coverage analysis enabled. Once it’s ready, you will get the results in the Unit Tests Coverage window.

Microsoft Fakes Support

Not much to say here. If you have tests that use Microsoft Fakes, dotCover will calculate their coverage. As easy as that!

dotCover. Microsoft Fakes Support

Note that Microsoft Fakes is supported not only by dotCover in Visual Studio (2017 or later), but also by the dotCover command-line tool. If you use the latter, you should run tests using vstest.console.exe (from Visual Studio 2017 or later).

Grouping Coverage Results by Namespaces

It’s a good practice to divide product features into separate namespaces. Now, you have the ability to see coverage results for a particular namespace, i.e. see the coverage of a particular product feature. This is how it works:

dotCover. Flatten Namespaces

You’re welcome to download the latest ReSharper Ultimate 2019.3 or Rider 2019.3 and check out the new dotCover capabilities for yourself. We look forward to hearing your opinions in the comments below!

Comments below can no longer be edited.

8 Responses to What’s New in dotCover 2019.3

  1. Avatar

    Pelle says:

    January 10, 2020

    Hi, coming from NChrunch for continuous testing, dotCover seems really slow. Is there any way for dotCover to automatically re-run only the affected tests without the need to do a build of the assembly? It seems to me that your “continuous testing” is just the normal testing mode with a run when pressing save(or build)? Am I missing something?

    (I know it’s not related to this blog post but wasn’t sure where to put my feedback/question)

    • Alexey Totin

      Alexey Totin says:

      January 10, 2020

      Hi Pelle,
      yes, dotCover works exactly as you described: it re-runs only the affected tests. Please make sure that ReSharper Build is used instead of MsBuild:

      • Avatar

        Pelle says:

        January 20, 2020

        Hi, I am using ReSharper Build, but it seems really slow compared to NCrunch. It takes ~5 seconds on a small solution before the tests start executing, compared to NCrunch < 1 second. Is there any way to make it faster?

        Kinda defeats the purpose if it is that slow :/

        • Alexey Totin

          Alexey Totin says:

          January 22, 2020

          Hi Pelle,
          dotCover works somewhat differently – it performs the “true” build of your project in order to run tests while NCrunch makes some kind of build “approximation” without actually building the project. Both approaches have their pros and contras.

  2. Avatar

    Per says:

    January 22, 2020

    I’m trying this out but Rider is not detecting any tests even though we have some in the project. Is there any setup I need to do?

  3. Avatar

    Mike-EEE says:

    January 22, 2020

    Are any efforts going to be made to improve a rather obvious and glaring usability issue with dotCover?

    It would seem that tests configured to run on build via continuous testing are also running on F5, meaning that whenever a website is launched, the tests also run, leading to a very awkward, slow, and degraded debugging experience.

    As it stands, I have to turn off continuous testing whenever doing website development, which basically now defeats the purpose of using dotCover.

    • Avatar

      Mike-EEE says:

      January 22, 2020

      FWIW I am getting a “520 Bad Gateway” error when posting comments with the “Notify” option checked and I thought this was “fixed.” :p

Discover more