Last week or maybe two weeks ago, I started to work on SpecFlow VS2013 support. Regarding VS2013, I belong to the not-that-early-adapters group, so I have skipped all the betas and installed the RC just recently. While working on the SpecFlow integration, I am trying to discover the new features.

The “what’s new” list of VS2013 is pretty short: to me the “peek definition”, the “enhanced scroll bar” and the “CodeLens” sounded interesting. Let’s take a look at the CodeLens now.

I’m one of those developers who like to keep tight control over the dependencies. I always want to know who is depending on the code that I’m currently working on. The “find references” is one of the most commonly used command (in ReSharper) when I am developing. So I was happy to see a new (and pretty innovative) way to visualize information about the code. The idea of CodeLens is simple: it shows information about type members “between the lines” – by displaying smaller non-editable info-lines in the source code editor. It can display different “indicators”, like references, related unit tests or TFS code collaboration information.

I have to admit that these info-lines confused me in the beginning. I was never sure whether there is an extra line between my code members or not (I’m not too picky about spacing, but I like to keep some kind of consistency in my source code.) I also tried to click into this read-only line from time to time, but I think I can get used to this.

Displaying the references is surprisingly fast and the small popup window that shows the details is handy. You can also enlarge the reference details to a full screen window. When I used it in practice, it was a little bit annoying that it does not display the reference information for all members. I like to track the references of my fields too.

The information about the related unit tests needs a little bit of clarification. The unit test information of CodeLens does not display test coverage information like the test impact analysis feature of TFS does. Instead, it displays the tests that are directly calling the particular method. The relation is calculated on the basis of static code analysis, so basically the same information is used as for displaying the references. Unless you do a simple demo, you will see that this information is totally different from the test coverage information you might have expected. This feature will not tell you if a piece of code in your application has or has not any (green) tests or which tests should be re-run after changing this code. It’s actually not easy to figure it out what it is useful for (…and the MSDN is silence…). Here is my try: “The test indicator in CodeLens is supporting TDD by linking the unit tests that have been written with the aim of testing the particular method.” So for the first look, this could be useful in TDD, where you write unit test for every public method and you want to have an overview of the tests created.

Besides the problems of the definition, there are some other problems I have seen. There are some cases where the test will not be displayed for a method, even though it is the unit test written for that code:

• the code resides in a private method, because you expose it as different public overloads
• the test code that is calling the method is extracted to a test helper method
• the method is called trough reflection (by some unit test helper library)

Even though these cases are not that common, it could be enough to loose your confidence in what tests to re-run. There is one huge benefit of the solution CodeLens uses however: the relation can be calculated very fast without impacting the test execution time. It’s a pity that SpecFlow tests will not be displayed at all (for the step definition methods, for instance), since SpecFlow uses reflection when bounds Gherkin scenario steps to the application code.

While figuring out these, I had to dig into the related Visual Studio code. The good news is that CodeLens, like the other features cooked recently  by the VS team, uses an extensible architecture. Therefore it should be possible to extend the available indicators with custom ones. (Like a SpecFlow test reference… I think I have my homework for the next weeks.) If you are also interested in the nasty technical details, search for the assemblies that have “CodeSense” in their name ;-).

The last (sad) thing  to mention is that CodeLens is only part of the Ultimate edition of Visual Studio, but the good news is that it works well with NUnit too, using the NUnit Test Adapter, although it requires an annoying change in the project file.