Hello everyone, We have good news for you today – Rider 2019.2 is released and ready for you to download! Here are the biggest and best things about Rider 2019.2: (more…)

Rider 2019.1 brings a lot of good news for macOS and Linux users: our profiling and code coverage tools are now supported (to varying degrees) on macOS and Linux. In this post, we'll dive deeper into the code coverage updates in Rider. (more…)

Today we are ready to introduce the first major release of ReSharper Ultimate family for this year – please welcome ReSharper Ultimate 2018.1! ReSharper gets a significant number of bug fixes (based on more than 260 requests) and a bunch of features and improvements as highlighted below: (more…)

Like all other products in the ReSharper Ultimate lineup, dotCover gets its set of improvements in the 2017.3 release. Let's check them out. Improved Show Covering Statements action Before 2017.3, after you used Show Covering Tests (Ctrl+Alt+K,T) in the editor, the popup window showed a list of covering tests. However, it didn't tell you what exact part of your code was covered by these tests: a class, a method, or a particular statement. Now, the popup shows this explicitly, and even highlights the covered statements in the editor: (more…)

Right after dotCover 2016.3 introduced a new way to highlight code coverage (markers in the gutter instead of colored backgrounds), we immediately got a flurry of “Bring it back!” comments. Indeed, there is a range of tasks where the “old-style” highlighting could be more useful, e.g. when you need to quickly evaluate uncovered parts of code. Some technological limitations prevented us from keeping the colored-background highlighting along with the new markers in 2016.3. Fortunately, now all the limitations are left behind, and dotCover 2017.1 gets the old highlighting back. And it’s even b

After we released the initial continuous testing support in dotCover, the most popular response was "Cool, but this could be a lot more useful if highlighting was able to indicate test results." Indeed, before 2016.3, dotCover's highlighting was used only to indicate code coverage: dotCover 2016.3 finally addresses the issue. First, we got rid of colored backgrounds. Now, we use a small colored marker in the left gutter. Second and most important, we've completely changed the highlighting logic. Now, it not only shows whether a statement is covered by tests but also indicates test resul

The recording of our June 10th webinar with Maarten Balliauw, .NET Code Coverage for Continuous Integration using TeamCity and dotCover, is now available on JetBrains YouTube Channel and slides on slideshare. In this webinar we use dotCover to collect code coverage information while running tests in our CI process. We can see how we can configure code coverage and how we can use the TeamCity Visual Studio plugin to download the coverage snapshot generated on the build server and inspect it using dotCover on a developer machine. How much of our code is being covered by our unit tests? A

Join us Tuesday, June 10th, 14:00 – 15:00 GMT (10:00 AM – 11:00 PM EDT) for our free live webinar, .NET Code Coverage for Continuous Integration using TeamCity and dotCover, with Maarten Balliauw. How much of our code is being covered by our unit tests? Are there areas we are not testing? By capturing code coverage data during a test run, we can analyze which areas of our applications are well-tested and which ones require additional tests to be written. And where better to capture code coverage information than on our build server? In this webinar we will use dotCover to collect code covera

Using dotCover, we can run coverage analysis on our code. We can verify which portions of our project are covered by unit tests and which are not. However, there are times when we don’t want to perform analysis on our entire project and instead want to target certain areas. This can be because we want our coverage analysis to run faster or because we want to exclude third-party or obsolete assemblies or classes from the resulting report. Let’s have a look at how we can setup coverage filters using Visual Studio. Since dotCover also comes with a console runner, we’ll have a look at setting up c

JetBrains developers and QA engineers are finally going to have some sleep since dotCover 2.0 RTM is available right now for you to download. Here's the list of features that make this a worthy upgrade: Support for Visual Studio 2012 RC along with Visual Studio 2005, 2008, and 2010. As soon as Visual Studio 2012 RTM comes out, we're going to release a minor update to support it. Integrated unit test runner. You don't have to have ReSharper installed to execute unit test coverage analysis anymore: dotCover 2.0 bundles the same unit test runner that ReSharper provides. However if you do hav

In an earlier post, we saw how to use dotCover in simple scenarios, whereby we have a single unit test project for which we want to obtain coverage reports on. There are times however, when this is not the case; that is, we might have multiple tests projects. It is very common (and recommended practice) to separate Unit test projects from Integration test projects, allowing us to run the former more frequently during development and the latter during an Automated Continuous Integration setup. In these cases, running the dotCover analyse command, as shown in the previous post might not be ideal

As of the beta* of dotCover, we included a Console runner to run coverage using the command line, allowing for instance, setup of dotCover in a Continuous Integration environment. Let’s see how it works. *To get all these features in this post, you need to download the latest nightly build Console Runner The Console runner is located under the installation folder (%Program Files%JetBrainsdotCoverv1.0bindotCover.exe). The best option is to add it to the system path so as to be able to run it from anywhere. The runner accepts several commands based on the operation we want to perform. Each of

In this short screencast you can see the basics of dotCover and how to get up and running in a matter of minutes.  

Last week we announced a new product by JetBrains for .NET developers: dotCover, a code coverage tool. We are aiming to open the EAP this week and some of our Academy Members have already been playing with it since last week. In this post I’m going to provide some more info on how it works. Code Coverage 101 Code Coverage is a means of measuring what percentage of your code is covered by tests. Technically,the higher the percentage, the less likely you are to find hidden bugs when it’s too late. You could therefore assume that 100% coverage is ideal, and you’d most likely be wrong. Having yo