JetBrains .NET Tools Blog

When working with TeamCity and Visual Studio, we can do a lot of things right from within our IDE. We can trigger a remote run, fetch dotCover code coverage information from the server, view changes and builds from a tool window, navigate to unit tests and a lot more. In this post, we’ll be looking at some of these features. But first things first: let’s install this nifty tool!

Installing the plugin

Every TeamCity installation ships with several tools for IDE integration (with our IntelliJ IDEA based tools as well as with Visual Studio). We can find the plugin on every TeamCity server under the My Settings & Tools page. We can download the plugin right there!

After downloading and installing the plugin, we can find a new menu item in our Visual Studio.

From this menu, we can connect to our TeamCity server using the Login… menu item. After entering the URL to our TeamCity server and providing the correct credentials, we can start exploring.

Remote run from Visual Studio

When developing a project in Visual Studio, we can initiate a personal build using the TeamCity plugin for Visual Studio. We call this a “remote run” because the build that is triggered runs on a TeamCity build agent, not on the developer’s machine. The interesting thing here is that this remote build uses the current version control repository sources plus the changed files in the developer’s IDE. All steps from the build configuration are executed for this personal build as well.

After changing some files locally, we can use the TeamCity | Remote Run (Local Changes) menu to trigger a remote build. In the dialog that opens, we can select the changes we made locally that should be included in this personal build. We can select all changes or cherry-pick just the changes we want to verify on the build server.

Note that we’re using Subversion as the source control system here. Remote Run is available for TFS, Subversion and Perforce. When using Git or Mercurial, the workflow is slightly different. Check the documentation on branch remote run for more information.

When we click the Configure personal build… icon in the toolbar, we have to make some other decisions. First of all, we must select the build configuration we want to use for the personal build. Next, we can provide a comment for this personal build. This comment will be shown in the TeamCity web UI afterwards to describe the personal build.

One interesting option is the Pre-tested Commit checkbox and its related commit if setting. Using this, submitted code changes first go through testing. If all tests pass, TeamCity will automatically commit the changes to version control and integrate it in the next build. When tests fail, the code is not committed and the developer who made the change is notified about this. Here’s a chart of the pre-tested commit workflow.

We can even customize our build: put it at the top of the queue or add additional build parameters.

After clicking the Run button, TeamCity will run the selected build configuration for the included changes. We can see the results in the TeamCity web UI, consult the build log, check unit test results and so on.

My Changes

Since this post is about the TeamCity plugin for Visual Studio, we can also verify the status of builds triggered because of our changes by using the TeamCity | My Changes menu.

Build log

From the toolbar, we can consult the build log for every personal build listed in the My Changes window. Clicking the Show Build Log icon (or right-clicking the build and selecting the appropriate context menu) will instruct the TeamCity plugin for Visual Studio to download the build log directly from TeamCity.

Open Failed Tests

Did your changes cause a unit test to fail? No worries: we can use the Open Failed Tests context menu from the My Changes window in order to see what is going on. From the window that opens we can re-run the failing tests locally using the ReSharper test runner.

Code Coverage

When you have dotCover installed on your machine, the TeamCity plugin for Visual Studio enables us to view code coverage results. Using the TeamCity | Coverage menu item we can select a code coverage snapshot to open.

After selecting and opening a snapshot, we get dotCover’s test runner showing code coverage. We can even double-click a class from the snapshot shown and explore code coverage at the statement level.

Investigate a build

Whenever a build fails, we can volunteer to fix the build by starting an investigation. From the TeamCity | My Investigations menu, we can manage our investigations and take action on open investigations by either fixing it or giving up (when working in developer teams in Belgium, that last option typically results in having to bring pastries for the team).

Open in IDE

The TeamCity web UI features an Open in IDE button on many places. For example, when inspecting changes that were included in a build, we can open the file that was built in our IDE by clicking the IDE icon.

We can open tests in the IDE as well, again using the Open in IDE function. When working with tests, this will trigger Visual Studio to open the ReSharper test runner and display the selected test.

Give the TeamCity plugin for Visual Studio a go and let us know what you think!

ReSharper provides comprehensive support for running and debugging unit tests. Out of the box, it works with NUnit and Microsoft’s Visual Studio Unit Testing Framework (henceforth mstest for brevity) for .Net languages, and supports QUnit and Jasmine for JavaScript.

The same APIs that ReSharper uses to implement this support are fully available to third parties, and there are currently plugins to expand this support to include Machine.Specifications (MSpec), xUnit.net and support for Silverlight projects. More can be added at any time, through the use of the SDK.

The MSpec project is a “Context/Specification” testing framework, which is a form of BDD tool, focussed more on driving correct behaviour than on testing functionality – building the right thing, rather than building the thing right. It’s a significant change of style to anyone used to the NUnit/mstest style of attributed methods, but it’s not too difficult to follow – test methods are replaced with fields that take lambdas that arrange, act and assert. It’s worth checking out the example projects in the source repository – BankingSpecs is a good place to start.

Machine.Specifications ships as a NuGet package, which also includes the ReSharper runner. Simply run the InstallReSharperRunner batch file in your packages\Machine.Specifications\tools folder (it includes support for ReSharper 6 and 7). Once installed, ReSharper now recognises MSpec tests in your source code, adding the unit test icons to the gutter in the editor:

One of MSpec’s nice features it that the names of the test and the information from the SubjectAttribute are used to generate a natural language description, which, when used with the different grouping options in the test runner can give very readable test results:

The xUnit.net framework is a more traditional unit testing framework, similar to NUnit and mstest, but arguably more idiomatic .Net. For example, it still uses attributes to mark methods as tests, but uses constructors and IDisposable instead of SetUp and TearDown attributes. Support is added by the xunitcontrib plugin, giving ReSharper the ability to locate and run xUnit.net tests. Like NUnit and mstest, it can handle parameterised row tests, dynamically adding rows into the results as the tests are run.

It also works with the “Show Unit Test Usages” option in the filter drop down of the Find Results window. When viewing the results of a find usage search, any usage in a test method or test class is marked with a test icon, rather than an icon representing a method, class or property. Unchecking the “Show Unit Test Usages” option in the “Filter Usages” drop down will hide the test usages in the results, allowing you to focus on the usages in the production codebase.

Unit test providers don’t need to be source based. Most of them are, and display the test icon in the editor gutter, but they also examine the metadata of the compiled assembly, and can potentially find more tests here. Using this technique, it’s possible to run tests created in a source file that ReSharper doesn’t support. For example, we can create an xUnit.net test in F#, and while it’s not detected in the editor, it is still found and run when the assembly is compiled.

Since the test hasn’t come from source code, you can’t double click the test in the test results to navigate to it. But a failing test will display a clickable stack trace that will navigate to the failure.

This technique can be used to run F# tests using other F# test frameworks, as long as they are based on a unit test framework that ReSharper supports (and this technique can also be used to write a plugin that supports a framework that isn’t based on one of these frameworks).

Silverlight support is provided by AgUnit, which enables running and debugging your unit tests in Silverlight projects, and of course handles the Silverlight test framework’s AsynchronousAttribute.

Perhaps surprisingly, a couple of our own products are also plugins for ReSharper’s unit test runner – dotTrace and dotCover. Although the products register themselves with ReSharper somewhat differently to normal plugins, these products use the same open APIs that the third party plugins use, albeit for a slightly different purpose. Instead of examining source code and metadata to find and run tests, they provide the environment in which tests are run; dotTrace collects profiling information, and dotCover collects coverage information. Both products extend the UI to provide means of running the tests, but dotCover also adds an output pane to the test runner to display the coverage information (and highlights covered and uncovered code in the editor), and of course, this works with third party test providers.

And, just to bring the extensibility full circle, dotCover includes ReSharper’s unit test runner, which is used if ReSharper isn’t installed. Again, NUnit and mstest support is provided out of the box, and there are separate dotCover plugins for xUnit.net and MSpec support (the dotCover MSpec runner is also distributed in the NuGet package, just use the InstallDotCoverRunner batch file in the tools folder).

ReSharper provides comprehensive unit testing support, in an environment that is very flexible. There is a lot of great support, provided in the box, and just a download away. And it’s all open and extensible – if you don’t see something you want, grab the SDK and get coding!

We are happy to announce the availability of dotCover 2.2! Please feel free to download and try it.

What’s new in this version:

• Integration with the recently released ReSharper 7.1
• Support for Windows Store Application Tests. Please note that with this version of dotCover you’ll be able to get overall coverage statistics, without percentages per single test
• This update also includes a series of bug fixes and improvements

For more details on improvements introduced in dotCover 2.x, please check out What’s New in dotCover page, and don’t forget to grab the latest build! Updated MSpec and xUnit plug-ins compatible with dotCover 2.2 are also available for downloading.

In case your dotCover maintenance period or upgrade subscription is still valid, this would be a free upgrade for you. And as usual, please feel free to provide us with any feedback.

Today we are opening the Early Access Program for the new version of dotCover, code coverage tool with integrated unit test runner. You are very welcome to download and try the latest build of dotCover 2.2.

The main purpose of this minor update is providing integration with the latest ReSharper’s 7.1 builds (best served with ReSharper 7.1.3.130 and 7.1.5.2).

Please download dotCover 2.2 EAP build, and let us know about any issues you might be facing via dotCover issue tracker.

As you might already know, last week we released an update to dotCover. This minor version includes a series of bug fixes and improvements as well as a couple of important features worth noting in details.

Visual Studio 2012 Integration

dotCover 2.1 now integrates fully within Visual Studio 2012, either as a standalone product using its own Test Runner, or integrating tightly with ReSharper.

In addition, it also comes with support for both Light and Dark theming, as well the ability to choose the icon set we want to use.

We’ve also added support to help with people with color-blindness.

Windows App Store Application Support

dotCover now allows the coverage of standalone Windows App Store applications, formerly known as Metro Applications.  This support is possible to the underlying engine that dotCover is built in, which is the same profiling engine that dotTrace Performance uses.

We have many more features planned for the next upcoming version of dotCover so stay tuned. And as always, please provide us with any feedback.

You can download the latest version which integrates with ReSharper 7.0.1 from here.

We are happy to announce the availability of dotCover 2.1 RTM build! Please feel free to download and try it.

This new version is notable for:

• Visual Studio 2012 support including the ability to choose icons and menu style according to the theme you prefer.
• Integration with the latest ReSharper 7.0.1.
• Calculating code coverage statistics for Windows Store applications (without unit test coverage yet).

For more details on improvements introduced in dotCover 2.x, please check out What’s New in dotCover, and  then download the new release!

Please note that if your dotCover maintenance period or upgrade subscription is still valid, this would be a free upgrade for you.

dotCover 2.1 Release Candidate has arrived! Please don’t hesitate to download and try the RC build.

If any critical issues are still bothering you, feel free to report them and have them fixed before release.

Starting today and all the way through September 14, as part of the traditional Back to School promotion, we’re offering discounted new personal licenses for ReSharper, dotCover, and dotTrace Performance.

For example, you can now buy personal licenses for:

• dotCover at $69 instead of $99
• ReSharper Full Edition at $149 instead of $199
• ReSharper C# or VB.NET Edition at only $99 instead of $149
• dotTrace Performance Professional at $199 instead of $299

Note that more JetBrains tools are being sold out during this limited-time offer, including IntelliJ IDEA, RubyMine, PyCharm, PhpStorm, WebStorm, and AppCode.

Think fast, you only have 2 weeks to decide!

We are glad to announce that dotCover 2.1 Beta is now available for you to download and try.

Calculating code coverage statistics for Metro applications, integration with Visual Studio 2012 including theming support and full integration with ReSharper 7 are the main changes of this update.

Please feel free to download dotCover 2.1 Beta, and let us know about any possible issues via dotCover issue tracker.

Today we’ve opened the Early Access Program for the new version of dotCover, our unit test runner and code coverage tool. Please, feel free to download and try the latest build of dotCover 2.1.

Here’s what’s new in this version:

• Integration with Visual Studio 2012 including support for Light and Dark themes. We have added Visual Studio 2012 theming support by updating menus and icons, so you can choose which appearance suits you best:
  
• Integration with ReSharper 7.0
• Calculating code coverage statistics for Metro applications (no unit test coverage just yet though):
  

Please download dotCover 2.1 EAP build, and let us know about any issues you might be facing via dotCover issue tracker.