Archive for the ‘dotCover Tips&Tricks’ Category

« Older Entries

ReSharper 6.1, dotCover 1.2 and dotTrace 4.5.2 Performance Released

Tuesday, December 20th, 2011

Christmas is only a few days away and we’ve decided to celebrate it a little earlier by releasing not one, but all three of our main .NET tools: ReSharper 6.1, dotCover 1.2 and dotTrace 4.5.2 Performance.

ReSharper 6.1

As covered in previous posts, this release of ReSharper is much more than a few bug fixes.

Settings

In ReSharper 6.0 we laid the foundations for what would be the new settings management engine. This was quite a substantial change, both from an architectural point of view as well as functional. Unfortunately due to that pesky little annoyance called time, we did not manage to finish it for the 6.0 release. We have now though and ReSharper 6.1 introduces a wealth of new possibilities for sharing settings across solutions, teams, machines and even company-wide policies. And we’re still not done with settings, so keep your feedback coming for further releases.

image

Performance improvements

For every single release of ReSharper, we invest a large amount of time in performance improvements. This often isn’t an easy task since new releases also include new functionality. In 6.0 we had some serious performance issues with certain types of web projects. This has now thankfully been resolved in 6.1 and we’ve made 6.1 faster in many areas. Numbers are impressive: we have fixed 140 performance problems for 6.1.

Async and Visual Studio 11 support

Async support in C# is still in CTP stage. Visual Studio 11 is in early developer preview. Trying to support technology that is not entirely finished proves not only challenging but also risky. Any major changes could deem most of the work we’ve performed as obsolete. However, we know that you, our users, play with the early bits and miss ReSharper.

image

That’s why in 6.1 we provide support for Async features in C# and VB.NET, as well as initial experimental support for Visual Studio 11. Support for Metro style applications is not yet included, and in order to install ReSharper into VS11 Developer Preview, you have to use a separate .vsix installer available at ReSharper downloads.

Optimizing assembly references

Many users rely on ReSharper in streamlining their project maintenance tasks, and this new feature is a nice addition to the existing project-level toolset. In any project in your solution, ReSharper 6.1 detects assembly references that are not effectively used, and helps remove some or all of them.

image

SDK

During 6.0 development we invested heavily in trying to provide a better API for extending ReSharper. 6.1 also sees the birth of this effort. Along with an improved API, we also now provide a testing framework, Visual Studio templates for creating plug-ins, samples, as well as online documentation. ReSharper 6.1 SDK is available for download as a .msi or .zip package.

image

More awesome features

Here are a few more great features also added:

  • Structural Search and Replace for HTML and ASP.NET. You can now use Custom Patterns to refactor both HTML and ASP.NET markup.
  • Call tracking for ASP.NET MVC. Same call tracking features, extended to ASP.NET MVC 3.
  • New code inspections. Access to disposed closures, covariant array conversions and more.

We have also fixed many outstanding issues. Look for more blog posts describing 6.1 features and improvements in future here on the JetBrains .NET tools blog.

dotCover 1.2 and dotTrace 4.5.2 Performance

These are mainly maintenance releases with a primary focus of supporting ReSharper 6.1. In addition, dotCover 1.2 works side-by-side with TypeMock 6.2.x, provides performance improvements in report generation, reduces HTML report size and memory consumption.

Note that we are already working on next major dotCover and dotTrace Performance releases. EAPs are expected soon, exposing a ton of new functionality and improvements, so stay tuned for that.

Download them all!

You can download ReSharper 6.1, dotCover 1.2 and dotTrace 4.5.2 Performance right now!

Last but not least, we’d like to wish everyone very Happy Holiday season. Stay safe and see you all in the New Year!

Tags: , , , ,
Posted in News and Events, dotCover Tips&Tricks, dotPeek Tips&Tricks, dotTrace Tips&Tricks | 18 Comments »

dotCover Console Runner Enhancements

Tuesday, October 18th, 2011

I’ve previously blogged about the possibilities of running code coverage using the dotCover console runner. You can find the Simple Coverage post here and the more Advanced post here. In dotcover 1.1.1 we made some changes to the console runner to facilitate the process even more.

Command Line Arguments

Previous versions of dotCover required that you specify the configuration parameters in an XML file. In dotCover 1.1.1, we now give you the possibility of defining these values directly on the command line in addition to XML Files. The way in which it works is similar to that of MSBuild, that is, you can define or override definitions in the XML file by passing them as arguments on the command line. For instance, take the following configuration file:

<?xml version=“1.0“ encoding=“utf-8“?>
<CoverageParams>
<TargetExecutable>mspec.exe</TargetExecutable>
<TargetArguments>tests.dll</TargetArguments>
<Output>output.dcvr</Output>
<InheritConsole>true</InheritConsole>
</CoverageParams>

If we want to override the Output , we could run this from the command line by passing in the Output folder argument:

dotCover cover coverage.xml /Output=new_output.dcvr

We can do this with any command (cover, report, merge, analyze, etc.) and with any parameter. Parameter names match one-to-one with the element names specified in the XML. As such, to override the <TargetExecutable> element, we would use /TargetExecutable=…., providing us with the flexibility of having a single configuration file and allowing certain parameters to be overridden when required.

InheritConsole

A new parameter is available in the cover and analyse command which is InheritConsole. What this does is inherit the console output of the target executable. This is useful for instance in passing messages to TeamCity log output (if for some reason you do not want to use the built-in dotCover in TeamCity). By default it is True.

Support for relative paths

One of dotCover’s earlier shortcomings was the inability to provide support for relative paths in configuration files. This has now been solved in version 1.1.1 also, providing the ability to define relative paths, both in the XML as well as command line arguments.

Relative paths defined in the XML are relative to the location of the XML file. Relative paths defined as command line arguments are relative to the location of the console runner working directory.

Coverage Result Descriptors

In earlier versions of the console runner, dotCover would produce what’s called Result Descriptors, which were index of snapshots. These files were normally required in an intermediate step for merging output of different coverage runs (see Advanced Coverage post for more details). This has also changed. Coverage now produces snapshots directly. This allows the generated files to be opened directly in Visual Studio using the Open Coverage Snapshot entry in the dotCover menu.

image

For backwards compatibility, intermediate index files are still supported, albeit new coverage calls will no longer generate these.

dotCover 1.1.1 is available for download here.

Posted in dotCover Tips&Tricks | No Comments »

dotCover 1.1.1 and dotTrace Performance 4.5.1 Released

Thursday, August 4th, 2011

dotCover 1.1.1 and dotTrace Performance 4.5.1 have been released!

dotCover 1.1.1

Despite the minor revision number, dotCover 1.1.1 introduces a ton of new features in the release.

ReSharper 6 Integration

With the recent release of ReSharper 6, we’ve been working hard to provide support for dotCover. As in previous versions, you can now run code coverage of tests directly from Visual Studio via the ReSharper test runner:

SNAGHTML1a469e3b

In addition, if you’re using ReSharper 6, you now get an additional icon (image) which allows you to cover all tests from the solution easily (accessible via the shortcut key Ctrl+U, K). Of course, ReSharper 5.x is also supported with this release.

Support for Dynamic NUnit Tests

dotCover now fully supports what are classified as dynamic tests in NUnit, i.e. those with variable input parameters and thus generated when tests are run. This includes the common TestCase attribute as well as Combinatorial, Sequential, TestCaseSource, Pairwise, Repeat as well as Random and Range attributes supported in method parameters.

image

image

This of course also allows a correct interpretation of tests covered by a certain section of code:

image

which corresponds to placing the cursor on the return statement and asking dotCover to Show covering tests (Ctrl+Alt+K). If we were to place the code on the exception we’d get:

image

as expected.

Exclusion/Inclusion Nodes Persistence

In dotCover 1.1 we added the possibility of excluding or including specific tests from coverage by selecting the node in the tree. We now provide persistence of these nodes between coverage runs (saved in *.settings file when saving snapshots), as well as support for Undo and Redo operations via the normal Ctrl+Z/Ctrl+Y key shortcuts.

image

Other Improvements

Apart from the previous, this release also includes

  • Optimizations in the area of snapshot storage, memory consumption and performance of multi-threaded applications.
  • Per-Snapshot settings, allowing snapshots to be saved along with node persistence exclusions as indicated previously (saved as *.dcvr and *.settings respectively).
  • Improved notifications during coverage analysis
  • Embedded progress bar in Unit Test Session Runner, as opposed to a modal dialogue
  • Warnings when no coverage for a selected test is found

Download from here

dotTrace Performance 4.5.1

This release of dotTrace has primarily been focused on integration with ReSharper 6 and minor bug fixes and improvements. Much like dotCover, dotTrace also supports the possibility of profiling all tests with one button click (image)  or using the shortcut key Ctrl+U, O. This feature is in fact available for any custom test host provider that use ReSharper’s test runner.

image

Other Improvements

This release also includes:

  • Shortcut provided (Ctrl+R) for editing configuration used for profiling without having to first return to Welcome screen.
  • Fix for OutOfMemory exception when constructing Hotspot Views
  • Support for Opening all method instances merged (Ctrl+Shift+T) in Hotspots View
  • Support for Adjust Time on special functions like Garbage Collector or Native Code
  • Fix for Registry Cleanup allowing Windows services to work as intended
  • Improved stability under IIS and ASP.NET
  • Fix of the computation of the total time of Children nodes for a root constructed as implicit recursive node
  • Work started on Profiling API

and more bug fixes.
Download from here

Tags: ,
Posted in dotCover Tips&Tricks, dotTrace Tips&Tricks | 1 Comment »

Using dotCover to Cover Applications, with or without ReSharper

Wednesday, April 20th, 2011

One of the main benefits of Code Coverage is that it allows us to detect certain areas, branches or lines of code that are not covered during a test run, which could lead to potential issues in production. We often write some code to find to our surprise that certain parts are never actually executed.

dotCover’s integration with ReSharper’s test runners, allows us to easily monitor what parts of our code are covered with tests. What happens though if we do not have tests? Whether we like it or not, there is a reality out there, and it’s mostly composed of legacy applications that have little to no knowledge of what a test is, let alone a unit test.

Although the ideal solution is to gradually add tests to existing code until we build up a good percentage of coverage, this is a process that takes time and is not accomplished overnight.

Covering Execution Paths

What dotCover allows us to do, independently of whether we have tests or not, is to execute an application and run an analysis report on what code paths of the application have actually been hit during the run. This often helps us track down not only potential issues (“I really thought that code was being executed”) but also resolve bugs (“Ah. So that’s why it’s not working”). Running Coverage of applications is a very simple process and does not even require ReSharper to be installed.

dotCover allows us to cover either an application that is currently open in a Visual Studio Project and selected as the Startup Application

image

or alternatively launch a non-executing Application:

SNAGHTMLb0d87fd

And as we can see, it covers a wide variety of application types.

Covering an MVC Application

The example below outlines an execution path of the MVC Music Store application. We open the project and select Cover Startup Application from the dotCover menu. This immediately launches the application allowing us to execute a certain scenario. In our case, we will select some items and drop them in the cart.

image

When starting coverage, dotCover also launches the Controller Panel, which allows us to grab a snapshot of the execution at any point we are happy with it.

SNAGHTMLb47486f

On clicking on Get Snapshot, the execution ends and we are returned to Visual Studio, were dotCover analyses the results and displays the Coverage Results Browser window

SNAGHTMLb49c05c

From here on, the possibilities of what we can do with these results are pretty much inline with that of running Code Coverage on our tests. We can examine coverage of projects, namespaces, classes and members. Navigate to a specific member as well as see in-place code coverage in the editor:

image

Exporting Results

New to dotCover 1.1 is the ability to export results to different formats, including XML, HTML, JSON and XML for NDepend. To export to HTML for instance, we select the Export icon from the Coverage Browser Window

SNAGHTMLb4f1afa

and select a destination to save the output too.

image

Summary

Although the more common usage of dotCover and in general all coverage tools are examining coverage of our code by tests, it is also useful at time to be able to run coverage of an application during a specific scenario, for testing or diagnosis reasons. Whether or not we have ReSharper, dotCover allows us to do that easily. Also remember that dotCover ships with a Console application which does permit you to run coverage of your Unit Tests from the command line and open up the results in Visual Studio.

Tags: ,
Posted in dotCover Tips&Tricks | 1 Comment »

Advanced scenarios with dotCover Console Runner

Thursday, August 5th, 2010

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.

Fine tuning the coverage steps

For the scenarios described, whereas we have multiple test projects, dotCover allows us to fine-tune the coverage process by offering us a series of commands that breakdown the coverage, merging and reporting into individual steps. Suppose we have the following Project Layout

image

The AppCode is our application code that we want to run coverage for, and TestProject1 and TestProject2 are specific the test projects that cover AppCode. These can be Unit Test or Integration Test projects. The process we need to follow is shown in the figure below:

image

We run coverage on each of the tests projects by using the cover (c) command using the following configuration file (corresponds to testProject1.xml. testProject2.xml is similar)

<?xml version=”1.0” encoding=”utf-8“?>
<CoverageParams>
<Executable>
X:\Libraries\nUnit\nunit-console.exe
</Executable>
<Arguments>TestProject1.dll</Arguments>
<WorkingDir>TestProject1\bin\debug</WorkingDir>
<Output>output1.xml</Output>
<Filters>
<IncludeFilters>
<FilterEntry>
<ModuleMask>AppCode</ModuleMask>
<ClassMask>*</ClassMask>
<FunctionMask>*</FunctionMask>
</FilterEntry>
</IncludeFilters>
<ExcludeFilters>
</ExcludeFilters>
</Filters>
</CoverageParams>

[Command to execute: dotcover c testProject1.xml]

Executing this command generates a snapshot file with coverage data, the Coverage Results Descriptor (by default, unless specified in the configuration file using the TempDir element, the snapshots are saved in the User temporary folder). These snapshots are not the final XML report that we are after but intermediate information that dotCover uses to generate reports from. There is a correspondence between snapshots and processes, such that each process generates a single snapshot. In our case, since we are calling a unit testing framework to launch a single test project, there will only be one snapshot. However there are cases, for instance when running coverage report on an application, whereby the application can launch another process  itself. In this case, multiple snapshots will be generated.

When we run this command, once for each Project, we end up with two snapshot files. We now need to merge the snapshots in order to generate the XML report. This is accomplished using the merge (m) command

<?xml version=”1.0” encoding=”utf-8“?>
<MergeParams>
<Source>
<string>output1.xml</string>
<string>output2.xml</string>
</Source>
<Output>output_merged.xml</Output>
</MergeParams>

[Command to execute: dotcover m merge.xml]

which takes the output of the two cover commands (output1.xml and output2.xml) and generates a single snapshot file. The only thing remaining is to generate an XML coverage report based off of this data, using the report command

<?xml version=”1.0” encoding=”utf-8“?>
<ReportParams>
<Source>output_merged.xml</Source>
<Output>results_merged.xml</Output>
</ReportParams>

[Command to execute: dotcover r report.xml]

providing us with the XML report containing coverage information (percentage of code covered, statements covered), which like in the previous post we can apply an XSLT to format into HTML or JSON.

Other Coverage Commands

dotCover provides two more commands:

  • list
  • delete

The list command simply obtains a list of all snapshot files given the coverage descriptors, that is, the output of the different cover commands. The configuration file lists these descriptors:

<?xml version=”1.0” encoding=”utf-8“?>
<ListParams>
<Source><!– Required. At least one child element expected. –>
<string><!– Coverage results descriptor 1 file name –></string>
<string><!– Coverage results descriptor 2 file name –></string>
<string><!– Coverage results descriptor N file name –></string>
</Source>
<Output><!– Required. Resulting file name. Stores plain list of all snapshot files. –></Output>
</ListParams>

The delete command deletes the list of given snapshots:

<?xml version=”1.0” encoding=”utf-8“?>
<DeleteParams>
<Source><!– Required. At least one child element expected. –>
<string><!– Coverage results descriptor 1 file name –></string>
<string><!– Coverage results descriptor 2 file name –></string>
<string><!– Coverage results descriptor N file name –></string>
</Source>
</DeleteParams>

Summary

As we can see, dotCover allows us to fine-tune the coverage process by letting us control the different steps. One question that might arise is why couldn’t we have done the same by running the analyse command twice, once for each Test Project. If we were to do that, we would get two independent reports, whereas here the results are all merged into a single report. The analyse command is a great fit for simple scenarios that only have a single project. Once we move onto more complex setups, having a finer control over the coverage process has its benefits.

Tags: , ,
Posted in How-To's, dotCover Tips&Tricks | 14 Comments »

Running Code Coverage from the Console with dotCover

Wednesday, July 28th, 2010

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%\JetBrains\dotCover\v1.0\bin\dotCover.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 these commands in turn takes one parameter, which is an XML configuration file. The commands are:

  • cover: Coverage of specified application
  • merge: Merges snapshots
  • report: Creates an XML report of the coverage results
  • list: Lists snapshots
  • delete: Deletes snapshots
  • analyse: Provides an all-in-one analysis and output

We can also obtain a list of commands by typing dotCover.exe help on the command line:

image

As shown in the figure above, we can find out more about each command by typing help followed by the command. All commands (including help) have corresponding shortcuts. For instance, to get information about analyse, we can type:

dotCover.exe help analyse

or

dotCover.exe h a

Since all commands take as parameter an XML file, when requesting help, all they do is generate a sample XML with comments indicating what each element means. The previous command would therefore output:

image

The obvious advantage to this is that we can easily get a new configuration file setup by just asking for help and piping the output to some file. In fact, adding a third filename parameter, dotCover will do this for us, without us having to touch up the output (remove headers, etc.).

Coverage in one command

The dotCover console runner is flexible in that it complies with most common requirements in a Continuous Integration setup. Normally in projects, we have multiple test projects we need to cover. We might then want to see the results separately or merge them as one report. dotCover allows for this kind of flexibility. However, in many cases, all we want to do is run coverage on a single test project and see the results. We’ll see how to do that in a single step in this blog post and in a future post we’ll get into the details or merging, listing, etc.

Let’s see how to do this step by step. I’ll be using a sample app that I’ve prepared for this blog post (using MSpec). You can adjust the parameters to your own project paths and unit testing framework as required.

 

  1. Type dotcover help analyse coverage.xml on the command line. I’m doing this in the root folder of my solution.

    image

  2. Add coverage.xml to the Solution and open it up in Visual Studio
  3. Eliminate all elements except the following

     image

  4. Fill in the elements with the corresponding values:

    Executable: Is the path to the unit testing framework runner (in this case mspec.exe)
    Arguments: Arguments passed to the runner, the test assemblies (specs.dll)
    WorkingDir: Optional path to the working folder (provide this to not have to fully qualify test assemblies)
    Output: XML Report containing coverage information. Relative to the coverage.xml path (output.xml)

     image

  5. That’s it in terms of configuration. Now all we need to do is run it by typing dotCover analyse coverage.xml. If all is configured correctly, we should see the following output:

    image

    and there should be an output.xml file located in the same folder. Opening it up we can see the coverage results

    image

 

Filtering from the Console

Looking at the results, we can see that there is a lot of noise, that is, assemblies that we’re not interested in such as the tests, MSpec assemblies, etc. In a previous blog post, we saw how to filter these out using dotCover GUI. Let’s see how we can do this via the command line. If we generate the default coverage configuration, we can see that there is a filter section:

image

These are used to filter assemblies. We can indicate which assemblies we want covered and which we don’t. In order to filter out all assemblies and concentrate only on our actual code (ClassLib), we can do one of two things:

  1. Filter out all non-required assemblies individually by adding them to the ExcludeFilters section, as in:

     image

  2. Exclude everything that’s not specifically in the Include section. This is done by leaving an ExcludeFilter section blank and placing what we want covered in the IncludeFilter:

    image

Based on the needs and depending on which of the two lists (Include or Exclude) are smaller, we can opt for option 1 or 2. The ouput should now be filtered:

image

 

Giving it some style

Only thing left to do is to format the output so that it can be viewed nicely inside a browser. This can be done easily using XSLT and some appropriate design skills (something I lack).

image 

Included in the project you have an XSLT to create some HTML as well as one to covert the XML to JSON. Having JSON output allows us to combine it with something like jQuery to display a nice treeview or grid with the results.

Tags: , ,
Posted in How-To's, dotCover Tips&Tricks | 13 Comments »

Screencast: Overview of dotCover

Tuesday, July 13th, 2010

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

 

Tags: , , , ,
Posted in How-To's, dotCover Tips&Tricks | No Comments »

Filtering with dotCover

Thursday, July 8th, 2010

dotCover allows us to run coverage analysis on our code. However, there are times when we do not want to perform an analysis on certain areas. This could be our test assemblies, certain third-party assemblies or even specific parts of our own project. Since the analysis has an impact on the overall statistics and potentially can take longer, it is often interesting for us to filter certain assemblies or classes out.

The figure below shows the coverage report of the default MVC project (yes, yet another MVC example, but it ships in the box and probably the ONLY template with VS that comes with tests). In this case we’re using xUnit for tests, which is mostly to demonstrate that dotCover works with other frameworks, not only MSTest (personally I’ve moved on to MSpec, which dotCover also supports).

SNAGHTMLfe87ba

If we focus on the Coverage results we can see that there are some areas in grey, which indicate that the corresponding PDB files were missing so coverage could not take place. We can also see other assemblies that have been included in the results yet might not be of interest, such as the test assemblies.

image 

In order to filter these out, we can use the Coverage Filters, which can be accessed via the dotCover menu in the IDE

SNAGHTML105d878

By default, everything is set to be covered, as shown by the Everything entry in the Allow Filters tab (which most likely will be renamed to Included). Examining this entry (clicking on Edit) we can see that it is composed of three values:

SNAGHTML107f54b

  • Module Mask indicates the project name
  • Class Mask indicates the class name
  • Function Mask indicates the method name

(All entries support wildcards as displayed by the * that appears)

We can now uses these patterns to exclude projects, assemblies, namespaces, classes and methods from out tests.

Excluding entire project

Click on Deny Filters tab (most likely will be renamed to Excluded) and click on Add, entering the following information:

SNAGHTML10eb8b9

Clicking OK  and re-running the tests, we now see that the entire test assembly has been excluded

Excluding an entire Namespace

We can exclude entire namespaces by setting it in the Class Mask as shown below:

SNAGHTML11da114

this will exclude all the classes inside the MvcApplication16.Models namespace. If we just wanted a specific class, we add it after Models instead of *.

Excluding a method

We can exclude a method, similar to how we’ve done it with the previous cases:

SNAGHTML12173ed

 

Adding a series of filters for test and auxiliary assemblies using the previous steps, we can end up with a cleaner and more accurate coverage report:

SNAGHTML1242f6e

produced by adding the following filters:

SNAGHTML1252438

Notice that by using the *.Tests (or alternatively as I call it *.Specifications), we can automatically exclude all our test projects from code coverage.

 

Beta Disclosure

Note 1: Currently these settings are Global, that is, they apply to all projects. Most likely we’ll be changing it so that they are Solution and Global scoped. This way, common libraries can be excluded for all solutions, and specific projects and/or namespaces can be solution based.

Note 2: We’re also looking at adding functionality to make it easier to define these exclusions (a la Right-Click on Folder, add to Excluded list)

As always, we’re still in beta and feedback is more than welcome!

Tags: , ,
Posted in How-To's, dotCover Tips&Tricks | 16 Comments »

Show Covering Tests with dotCover

Tuesday, July 6th, 2010

One of the new features dotCover has added is the ability to find tests that cover a certain piece of code. Something remotely similar has been available in ReSharper, although it has been kind of an archaic solution (i.e. Find Usages on Method calls, locate Test assemblies in Result window).

dotCover makes this easier by providing quick access to this information and extends it in functionality.

Below we can see some tests from an MVC application. Let’s run Code Coverage on it using dotCover first.

image

Now let’s switch over to the Source Code and select some random source code, in this case the MembershipService.ChangePassword line in the ChangePassword action:

image

In order to see the tests that cover this line of code, we can either press the default key combination of Ctrl+Alt+K or select the option Show Covering Tests from the dotCover:

image

dotCover will then display a small window showing all the different tests that cover that line of code.

image

At this point, we can run the selected tests or add them to the existing ReSharper Test Runner session. This allows us to easily jump from specific sections of code to the corresponding tests and execute them instantly.

One minor note: The default key mapping conflicts with KeePass, but you can easily re-assign it via Visual Studio Tools | Options | Keyboard, or do as I did and change KeePass to Ctrl+Alt+P (P as in Password…makes more sense).

SNAGHTML5841541

Tags: , ,
Posted in How-To's, dotCover Tips&Tricks | 10 Comments »

Sample SSR Pattern Catalog Available for Download

Wednesday, June 2nd, 2010

A while ago we introduced Structural Search and Replace, a new powerful feature in ReSharper 5 that lets you search for custom code patterns and replace them with other patterns, facilitating batch removal (or improvement) of stinky code.

We were hoping to include a set of ready-to-use search and replace patterns into ReSharper 5.0 release but it just didn’t happen. Instead, we’re publishing a sample Pattern Catalog on the web site for you to download.

The sample Pattern Catalog currently contains 17 patterns to search for and replace unreachable code, redundant compound assignments, clumsy method chains, and other pieces of code that you’d better get rid of.

As soon as you’ve downloaded and unzipped the Pattern Catalog, do the following to import it:

  1. In Visual Studio, choose ReSharper | Tools | Pattern Catalog.
  2. Click Import and select the XML file that contains the sample Pattern Catalog.

Tags: , ,
Posted in How-To's, ReSharper Tips&Tricks, dotCover Tips&Tricks, dotTrace Tips&Tricks | 8 Comments »

« Older Entries