Continuous delivery

Code inspection on build server using ReSharper Command Line Tools

Did you see source code with VS scrollbar full of different colors and warning sign in every file? For a long time that was my case. It did not help that we agreed on some coding guidelines within our team. If some rules are not enforced, then code issues will get into your source code – doesn’t matter if it’s rush, manual refactoring, merging conflicts or less careful teammates. To avoid that the best way is to make code inspection part of your bulid pipeline.

Continue reading

Programming (back-end)

Debugging NSpec with VisualStudio/Resharper – simple trick

NSpec is purely awesome, although coming with little painful disadvantage – debugging. The default approach (DebuggerShim.cs) is weak because forces me to always navigate to a separate file and change some code. Authors of this great library claim in the documentation that they already work on “fully integrated support”, but it’s not there yet. Fortunately you can apply one simple trick to make it work far better.

1. Get Nspec: install-package nspec

2. Get NUnit (in version referenced by NSpec): install-package nunit -Version

3. Go to DebuggerShim.cs file and change it to look like that:

nspec - DebuggerShim.cs

And that’s it! You can go back to your specs and be delighted by the “unit test” icon beside your spec class.

NSpec - test result

…and test runner:

NSpec - Run spec

What has happened?

DebuggerShim was a tool (nunit TestFixture) that run some given specification. By renaming it to “nspec” class it’s become a wrapper for all specifications. For NSpec it doesn’t matter because it doesn’t care about NUnit attributes nor abstract classes. If it’s in the same namespace as other specifications, then we do not have to change anything and Resharper starts to detect it as NUnit test fixture (as it derives from our custom “nspec” test fixture).


  • Simple – no need to install any plugin/adapter
  • Unobtrusive – no need to change existing specifications
  • Easy to update – if NSpec gets fully integrated debugging support, then just delete custom abstract nspec wrapper
  • Additionaly as a test output we see specification generated by NSpec runner


  • It runs the whole specification, it’s not possible to debug single context. This is particularly painful in case of big (and slow) UI testing scenarios. In that case I try to split them into several more specific scenarios.

You can download the test sample here:

Programming (front-end)

Unit testing JavaScript with VisualStudio and Resharper – running on buildserver + code coverage using Chutzpah


Unit tests are priceless but only when run automatically. Otherwise they can become forgotten and stay red (or ignored) for the rest of their lifetime. In the last two posts about unit testing in Javascript [1, 2] we have prepared our solution. Now it’s a very good time to tell our buildserver to run them during the build process. I chose Chutzpah as the test runner.


Chutzpah, pronounced [hutz-pah] from Yiddish/Hebrew, means “shameless audacity, utter nerve”. It’s a JavaScript tests runner that uses internally PhantomJS, Jasmine/QUnit to run the tests and BlanketJS to generate code coverage. The package contains both VisualStudio extension to run the tests (but I prefer Resharper) and console runner used by buildservers (especially TeamCity). Beside its core functionality chutzpah can also generate report with code coverage of JavaScript. Among all known approaches to run javascript test, in my opinion using Chutzpah is the simplest.

Getting started with Chutzpah

  1. Download Chutzpah and extract it to some well-known place (in my case C:\BuildTools\chutzpah)
  2. Add chutzpah.json configuration file to the test project folder. This step is optional for chutzpah, but in our case we use root path while referencing files in unit tests and this needs to be configured specially in the config file (there is also some additional information about code coverage pattern):3
  3. Run chutzpah console runner with parameters:
    /path – place where all the testes are
    /codecoverage – tell chutzpah to generate html report with code coverage


There is also an extra output file with code coverage information:


Preparing package for build server

Now we are able to run tests on build server – just run chutzpah.console.exe with specific parameters. the build should fail if any test fails. The other thing is the reporting to the build server about the test result. Fortunately Chutzpah has built-in support for TeamCity (/teamcity command line swith) but also serves XML output (/junit switch).

To have it on Teamcity I needed only to prepare MSBUILD file with the build procedure (I prefer to have everything in source control, especially build procedure, that’s why I don’t believe in TeamCity build steps):1

After adding this file to TeamCity we should see:


And after configuring report tab for “JS Code Coverage”:


Have fun!


Download and play with the demo solution:

Programming (front-end)

Unit testing JavaScript in VisualStudio with ReSharper – improvements

This is another approach to the previous subject: Unit testing JavaScript in VisualStudio with ReSharper. I kindly encourage you to get back to it before further reading.

Referencing production code in Test project

Last time I suggested “link-referencing” files with production code. Then during the build process files were copied to the test project. This approach was a bit cumbersome:

  • we had code duplication in our solution structure
  • sometimes it wasn’t obvious which file was edited – original file or the file copied to the test project
  • R# was complaining about missing references before the build process
  • You need to prepare test project file (.csproj) to make it work
  • You need to reproduce reference structure and keep it up-to-date while working with tests

Fortunately there is a cleaner approach to referencing production code. The solution is to reference files using root reference path:image

In this case we get the root of the test project, go to parent folder (..) and take the files directly from the project with production code (FrontEndTools). Now the only disadvantage is that each test file should know what’s the name of the folder of the tested project and change it when the folder name is changed – but this is very rare case, isn’t it?

If your Resharper marks the referenced file red, add reference to the tested project (FrontEndTools in my case).

From now on the solution structure looks much cleaner:


Switching to Jasmine

Previously I mentioned that I prefer QUnit with its TDD style, but after some time using both I changed my mind. Here are some of my thoughts:

  • Jasmine is more popular – I don’t have any statistics, this is just my feeling after browsing some open source projects and mixing with angularJS communities – I’ve just found Jasmine as a standard
  • Jasmine with its beforeEach/afterEach is more similar to NUnit SetUp/TearDown
  • Jasmine has own (extendable) matchers that simplifies doing even complex assertions
  • Built-in mocking framework is awesome – and this is actually killer feature – in QUnit you should build mocks manually or add external libraries (like SinonJS)
  • Both are supported by default (and only these two) by Resharper
  • Both have very good support and community background (with plugins and extensions)

Other demo solution improvements

  • jasmine.js referenced to test scenarios – Jasmine is by default supported by Resharper, but to get IntelliSense and get rid of Resharper annotations it’s good to reference proper Jasmine.js file explicitly
  • added tests for ColorBoxViewModel with a sample of Jasmine mocking


You can download the demo here:

Programming (back-end)

Find unused private and public methods with Resharper

7There are times when you find dependencies of some legacy code in a method that is never used. I personally always have a feeling that one day I need to find a way to search for all these unused methods and just get rid of them. Here I want to show you how to do it with Resharper.



There is a nice inspection tool built into Resharper that can show us different code issues found in the solution. Among them we have a metric called “Type or type member is never used”. By default it presents private types and type members (methods, fields, properties, etc) that are never used. To make R# show us also public (or in general ‘non-private’) types and members you need to enable “Solution-Wide Analysis”.

1. Go to bottom-right corner of visual studio, right click the circle and click “Analyze Errors in Solution”


2. You should see a message that solution-wide analysis could take a while, but don’t be scared, for me analysis of a big project (more than 60 000 statements) took less than 2 minutes.

3. Go to “Resharper –> Inspect –> Code issues in Solution” (or current project if you wish).


4. After code analysis it should show the inspection result. To filter only the unused methods (type and type members) click “Filter issues” button.


5. In the “Filter Issues” window “Uncheck All” options and then go to “Redundancies in Symbol Declarations” and check “Type or type member is never used” (here you can specify that you want to see only private or non-private stuff).


6. After that you can group the report by some additional criteria – I prefer project structure. From now on you can click each and every issue and do some actions on it (mainly “Remove unused …”.


Final notes

Although we have a full list of unused types and type members, we cannot bulk remove the issues and forget about them. Some of the issues should be treated specially because they can be used in ASP.NET markup, WCF communication, serialization and any other way that cannot be figure out by Resharper. All in all it’s good that unused interface implementations will not be taken as issues.

Happy refactoring. And don’t forget to turn off Solution-Wide Analysis.

Programming (front-end)

Unit testing JavaScript in VisualStudio with ReSharper

imageCurrently a huge number of projects is driven by TDD. There are tests of Services, Repositories, Domain objects etc. The attitude to these kind of practices changed and now it’s nothing exciting but our bread and butter. Moreover the architecture of current Web Applications changed as well. In average we spend more than 50% of our time developing front-end side of the app (JavaScript etc) but having in mind, that TDD is only applicable to back-end code. As a ReSharper user I’ll show how easy it is to set up a proper solution with another level of unit testing.


Test application

Let’s imagine that we are doing a web application supporting front-end developers. Among all the functionalities we have a simple reusable module to recalculate color values: RGB/HEX.


Separation of Concerns is one of the most important things while doing TDD, that’s why I chose “KnockoutJS” as the framework connecting our view with the logic. Architecture of such application is very simple. At the moment we don’t even have any “back-end” code, but still can do TDD.


The first test

Let’s pick out the ColorCalculator as the target. This is a “class” that is responsible for calculating color values between RGB and HEX.

Thank to Resharper 6+ we have JavaScript test runner provided out of the box. We can write JavaScript tests with two frameworks: QUnit (TDD style) and Jasmine (BDD style). Here I chose QUnit but you can see version with Jasmine in my next post: Unit testing JavaScript in VisualStudio with ReSharper – improvements. Because these two framework are supported by default, we don’t even have to download/reference any additional libraries. This is how our basic test will look like:


Immediately after closing the test() function resharper will add “Run test” button on the left. In case of QUnit Resharper will run the test in the default browser using QUnit default template, showing the result as it is:


Test result is also shown normally in ReSharper “Unit Test Sessions” window.

Extracting test project

Of course it’s not the best choice to have tests shipped with production code. For most of modules for back-end code we have dedicated “.Test” project. Now let’s extract such a separate project for JavaScript test code.

First add a new project to the current solution. The project type should be “Empty Web Application”  (in contrary to normal unit test project when we add “Class library”). Then you can add your test files to the project. You also need to reference the tested code. To do it, add existing script files as “links”:


This is the drawback of our solution. Whole reference tree needs to be reproduced . But it’s not that bad, we don’t change the reference tree that often but instead we have all the code in one place and it’s checked during the build time. Complete test solution should look like that:


Next you need to do a little trick to copy referenced files to the solution. To do it “Edit project file” and add the following code to the end of the test project:


I hope in the next releases of Visual Studio such behaviour will be applied automatically.

Finally modify a little the test code adding a reference to the code under testing (/// expression):


And that’s it! – after adding some tests and implementing the functionality correctly you can right click the solution, click “Run all tests” and be sure that everything is correct!

UPDATE: There is also better and simpler approach to reference production code. I write about it here: Unit testing JavaScript in VisualStudio with ReSharper – improvements

Debugging the tests

Wiseman said: “If you need to debug unit test then something is wrong with it’s unitness.”

PS: If it’s really needed you can debug it in browser as you normally debug JavaScript code.

Switching to PhantomJS

If you don’t want to run the tests in browser you can run it with headless PhantomJS runner (also by default supported by ReSharper). Go to “Resharper –> Options –> Unit testing –> JavaScript Tests” and change the “Run test with” option:


You need to specify the path to PhantomJS that can be downloaded from here.

Further reading

I write also about some improvements in this area (Test framework, Mocking, Referencing production code) and integrating JavaScript unit testing with our build server:
Unit testing JavaScript in VisualStudio with ReSharper – improvements
Unit testing JavaScript with VisualStudio and Resharper – running on buildserver + code coverage using Chutzpah

Download and play

You can download the whole solution here:

There’s still a lot to do – you can add tests to the ColorBoxViewModel and test “toRgb” function that is far more interesting.
Happy testing!

Programming (back-end)

Resharper template for unit test method (replacing spaces in the test name with underscore sign)

Resharper live templates are great to automate repetitive work. An example of such work is unit test method. In the first part I’ll show how to create a basic template that will build the structure of a unit test. In the second one I’ll show how to make R# give a correct name to such test based on human-readable description.

Test template

Below we have an example of a test method in AAA style:

public void when_doing_something_then_expect_something()
   var x = 100;

   var result = this.Calculator.Sqrt(100);

   Assert.AreEqual(10, result);

As we can see to create a nice structure of AAA unit test we need to remember about three comment labels, attribute, correct test name. Such structure can be easily extracted as resharper live template. To do it:

1. Go to Resharper –> Templates explorer

2. In “Templates explorer” select “C#” section and click “New template”:



3. Fill in live template form – edit shortcut and content:


After that the new template is ready to be used. Just type the shortcut entered before, click ENTER and this is it!


Converting a sentence into a valid test name

Another problematic thing in writing unit tests is naming the test. We want to give self-describing names to tests. Sometime it’s a rule, to name tests like “When something then something”. This way we use a human-readable sentence in a place, where spaces between words are not allowed. Thus we are forced to replace them with underscore (‘_’) sign, or capitalize each word – both ways are highly uncomfortable and drive developers mad.

However it is possible to use resharper macros to do additional logic for template fields. We can choose a macro for each field (look at the picture of the template form). Unfortunately here is a first disappointment – there is no bult-in macro to achieve this. It’s even worse, because there is a macro called “Value of another variable, where spaces will be replaced with ‘_’”, but this one cannot be applied to the same variable (test name in our case).


To overcome this disadvantage it’s needed to create custom macro applied as a plugin. Below there is a code of the macro:

            LongDescription = "Replace spaces with '_' (i.e. \"should return nothing\" into \"should_return_nothing\")",
            ShortDescription = "Replace spaces with '_'")]
    public class SpacesToUnderstrokesMacro : IMacro
        public static string Evaluate(string text)
            return text.Replace(" ", "_");

        public ParameterInfo[] Parameters
            get { return EmptyArray<ParameterInfo>.Instance; }

        public HotspotItems GetLookupItems(IHotspotContext context, IList<string> arguments)
            return null;

        public string GetPlaceholder(IDocument document)
            return "sentence with spaces";

        public string EvaluateQuickResult(IHotspotContext context, IList<string> arguments)
            if (context.HotspotSession == null || context.HotspotSession.CurrentHotspot == null)
                return null;
            var currentValue = context.HotspotSession.CurrentHotspot.CurrentValue;
            return Evaluate(currentValue);

        public bool HandleExpansion(IHotspotContext context, IList<string> arguments)
            context.HotspotSession.HotspotUpdated += this.CurrentHotspotUpdated;

            return false;

        public void CurrentHotspotUpdated(object sender, System.EventArgs e)
            var hotspotSession = sender as IHotspotSession;
            if (hotspotSession != null)

To compile, it is needed to reference the following R# libraries (from the installed version of R#, in my case R# 7.0):


Most of the code is about implementing the standard IMacro interface. Most important here is the method EvaluateQuickResult that evaluates the value of the current field (hotspot) in a template. The same function is invoked each time the HotspotUpdated event is triggered.

Newly build plugin can be now added to resharper. Just copy it to “C:\Users\some.user\AppData\Roaming\JetBrains\ReSharper\v7.0\Plugins” folder and restart VisualStudio. After that the new macro can be added to the template and the test name will be transformed to the valid identifier on the fly.


Instead of building your own plugin, you can also download it from here


I also highly recommend creating another macro just to replace spaces with ‘_’. I’ve got ‘testn’ = ‘test name’ and it’s used extensively for renaming unit tests