ReSharper: Don't use Visual Studio without it!

According to IntelliBrains, ReSharper is:

the most intelligent add-in for Visual Studio 2005, 2008 and 2010 that provides a rich set of features to boost individual and team productivity in the world of .NET development.

Ooo! Marketing speak! Allow me to translate:

ReSharper is a Visual Studio add-in that adds over 70 features to the development environment. I linked directly to the feature list on the ReSharper web site, because there are just way too many for me to cover here, and they do a good job of showing you the salient points of each feature. But, I would like to point out a few of my favorite features: (I borrowed the images from the ReSharper web site to save me the time.)

Code Analysis

As I type, ReSharper is analyzing my code, looking for several things:

  • Errors (“that code won’t compile”),
  • Warnings (“that code may cause a null reference exception at runtime”),
  • Suggestions (“the type of that parameter can safely be changed to its parent class”), and
  • Hints (“your code might be easier to read if you invert that if statement”).

ReSharper Hint

This, to me, is the single most valuable feature of ReSharper. I would not code nearly as fast without it.

Navigation & Search

ReSharper offers several “Go To” tools that will significantly speed up your navigation of your code:

  • Go To Type (CTRL+N) takes you to any type in your solution, even by typing just the upper case letters (a feature JetBrains calls “CamelHumps”):

ReSharper Go To Type

  • Go To File (CTRL+SHIFT+N) takes you to any file in your solution – a huge help on huge projects.
  • Go To Symbol (CTRL+SHIFT+ALT+N) takes you to any method or variable in your project.

Refactorings

Here’s a picture of a small subset of the refactoring support in ReSharper:

image

One particularly interesting one in that list is “Use Base Type where Possible…” which is a very good habit. Using abstract classes and interfaces allows you to break coupling in your code. I could write several blog posts about just this one refactoring. Admittedly, though, my use of the refactorings tends toward smaller scale things like “Extract Method” and “Inline Method”.

 

Code Generation

Advocates of the agile practice called Test Driven Development (like myself) have long derided Visual Studio for offering to write unit tests for code that already exists, but not offering the opposite feature – generating method stubs from tests that were written before the code existed. ReSharper fills that gap quite nicely:

ReSharper method generation

If you do TDD in Visual Studio, this feature alone will pay for ReSharper. (And, if you’re not doing TDD, why not?)

Coding Assistance

Here’s a feature I didn’t even know existed until I started writing this article. It’s called “Complete Statement” and it automatically completes the current statement.

When you reach the end of a statement, like this:

ReSharper Complete Statement 1

Simply press CTRL+SHIFT+Enter and ReSharper completes the statement, and places the insertion point exactly where you’d want it, like this:

ReSharper Complete Statement 2

I think I’ll be trying that one out later today.

Code Cleanup

Ever open a file and discover that whoever created it had their tabs set to 2 spaces, making the text too dense and the indentations too shallow for you to quickly grasp the structure of the document? ReSharper can help you there, too. Simply press CTRL+ALT+F to format the file using your preferred format settings.

Code Templates

ReSharper completely replaces the rather limited Visual Studio “Code Snippets” feature with their own Live Templates feature. Here’s an example of their “foreach” template at work:

ReSharper foreach Template

Notice that ReSharper knew which object you were likely to want to iterate over. Very smart. Very useful. To access the feature, press TAB after typing in the name of a live template, in this case “foreach”.

Unit Testing

ReSharper automatically detects NUnit and MSTest-based unit tests in your projects and allows you to run them directly within the Visual Studio user interface. The runner is not perfect – JetBrains doesn’t always quickly add support for new features as they are added to the unit test frameworks. For example, ReSharper 4.5 does not support the NUnit [TestCase] attribute for creating data driven tests. But, I rarely use the [TestCase] attribute when doing TDD tests, which is primarily how I use the unit test runner.

In Conclusion…

If I still haven’t convinced you to take a look at ReSharper, I recommend taking a look at their website before writing it off completely. There are so many useful features that I didn’t cover here, you’re bound to find half a dozen favorites of your own. Heck, even if you’re already using ReSharper, spending some time on their website will likely show you something you don’t know about the product.

FxCop

It has come to my attention that not everyone knows about or uses all of the development tools I know about and use. As such, I’m going to start a series of posts about development tools you should be using, starting with FxCop.

FxCop is a “static analysis” tool from Microsoft. Here’s how they describe it:

FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.

Here’s what it looks like:

image

FxCop comes with a large suite of rules for evaluating software assemblies. To run it, compile your software, open FxCop, select a target (Project / Add Targets…), select the rules you want to include (Rules tab) and click Analyze (on the toolbar).

What you get is a list of all the places your code violated the selected rules (in the right hand pane) and details for each violation (in the lower pane). As you can see from the size of the position indicator in the scroll bar, running FxCop on the new WCF middleware interface (Symetra.Services.Middleware.dll) produced quite a few errors. (Yikes!) Looks like I’ve got my work cut out for me before I put that code to bed.

Static analysis tools like FxCop are typically run during an automated build process to ensure that all of the developers on a team are following sound development practices. As Microsoft mentioned (above) FxCop is specific to design, localization, performance and security. Another Microsoft tool called StyleCop can alert the team to violations of the team’s coding standards. But, that’s another post.

For now, I hope you found this post handy. Because, to paraphrase Red Green: “If the developers don’t find us architects handsome, they should at least find us handy.”

UPDATE: I thought of a few more things to point out this morning:

  1. Note that the FxCop bits can be found in AccuRev under the Lib\FxCop folder.
  2. I setup the WCF Middleware Service stream to “include” the latest FxCop bits from the stream entitled sym_Lib_FxCop_1.3.6.
  3. I checked-in .FxCop ruleset file in the same folder as the .sln file. I also added it to the solution in a solution folder, so it would be in my face – and I might remember to run FxCop locally before checking in my code.

Lean Software Development

In my previous life, as a developer on the Microsoft Visual Studio Team System Process Team, I helped design workflows for user stories and other types of work items. These workflows were to be integrated into the process as a status field on the work item. At one point, we identified a workflow that boiled down to something like this:

  • New
  • Grooming
  • Groomed
  • Developing
  • Developed
  • Testing
  • Tested
  • Deploying
  • Deployed
  • Accepting
  • Accepted

At the time, we felt that it was important to make a distinction between items that were actively being worked and those that were waiting for the next stage of the process. In the end, we simplified the status field by dropping all the active verbs (those ending in “ing”), in favor of assuming that all work in the current sprint was active.

Part of me likes that decision – it certainly simplified the workflow. But, part of me, to this day, bemoans that decision because it limits a team’s ability to identify waste within the process that needs to be eliminated.

Imagine a process for building widgets. In this process, each widget starts life as raw materials. These materials get flobbled, marned, and volmed before becoming actual widgets. As materials move through the process, sometimes there are too many to marn all of them at once. So, those “in-process” materials sit and wait for their turn at the marner. Similar delays may also happen at the flobbling and volming workstations. And, of course, at any time, one of the machines could break causing downstream process points to run out of work.

This is a typical manufacturing process. And, it’s just like the software process described above.

In Lean manufacturing (a process improvement method invented by Toyota) the time a piece of work has to wait for a machine is considered waste. (It was a waste of money to buy more materials than the process can handle.) Likewise, the time a machine has to sit idle waiting for the next piece of work is also considered waste. (Idle infrastructure is a waste of the investment incurred to obtain and operate said infrastructure.) Lean manufacturing seeks to eliminate all of that waste. Out of this movement have come innovations like just-in-time inventory.

Likewise, in Lean software development, time spent in the inactive states (those verbs ending in “ed”) is considered waste to be eliminated. In other words, why groom 20 stories when the developers can only work on five at a time. The Product Owner may never prioritize some of the other 15 groomed stories high enough for the team to work on them, rendering moot the effort spent grooming those abandoned stories. Likewise, why continue developing code when there are broken tests? Until the tests are fixed, nothing can move forward in the process.

Scrum lends itself to Lean software development through its iterative, incremental approach to building software. So, the team only needs to groom enough work for the next sprint, for example, reducing the potential for time to be spent grooming stories that will end up being abandoned.

The metaphor breaks down a bit, though, when you run into a particularly urgent but poorly understood request from the business. It may take so much time to groom that development stalls, waiting for well understood requirements. This is wasteful in that the developers and testers (the infrastructure of software development) are idled. Extreme Programming’s approach to this situation would be to punt the poorly understood requirement until such a time that it can be adequately articulated. Scrum is less, um, confrontational, but no less dependent upon adequately articulated requirements.

As with everything else on this blog, I just needed to get this out of my head. I hope you found it interesting and/or useful. But, if not, at least my brain can now move on to something else.

The Matrix Reloaded

I wrote this post quite a long time ago – right on the heels of my original test matrix posts. Why I never posted it is beyond me. I’m posting it now to get it out of my “drafts.”

---

A few posts back, I discussed The Marick Test Matrix and my minor modifications to the matrix. In those posts, I described how to classify different types of testing into the four quadrants of the matrix. It turns out that you can also use the same matrix to classify testing tools, like this:

image

Let’s look at each quadrant, in more detail, starting on the right hand side:

Business/Defects

This quadrant represents those types of tests that identify defects in business (or non-technical) terms. In other words, you don’t need to be a programmer to figure out that there is a defect.

Typically, these tests are not automated. So, there are no automation tools to discuss, here.

Technology/Defects

This quadrant represents those types of tests that identify defects in technical terms. In other words, you probably need to be a programmer to figure out that there is a defect. Therefore, one would expect the tools in this quadrant to be highly technical and to require specialized skills. In fact, there are people who specialize in this work. They are typically called testers; but, their knowledge of programming is often greater than the average developer.

The dominant tool in this space is Mercury LoadRunner. Microsoft also has tools in this space, including the Visual Studio Team Test Load Agent and the Microsoft Web Application Stress tool (MS WAS).

Business/Requirements

This quadrant represents those types of tests that define requirements in business terms. As such, you would expect the tools in this category to be (relatively) non-technical. Business Analysts and end users should be able to use these tools to create automated tests without knowledge of computer programming. In fact, these tests should be written by those team members with the most business expertise.

FIT, FitNesse, STiQ, WebTest and Selenium are all examples of tools that allow tests to be expressed in business terms. All of these tools are well suited to use by Business Analysts.

Technology/Requirements

The testing that takes place in this quadrant defines requirement in technical terms. Therefore, you would expect to see lots of low-level, code-based tools, here. These tools are generally used by computer programmers (e.g. developers and testers).

JUnit and NUnit are the big dogs in this space. Other tools include MSTest, WatiN, MBUnit, xUnit, RSpec (for Ruby), and NUnitASP.

Votebox

As much as I love Rally for managing work, I think I may have found something better. Votebox is where Dropbox users can request features and vote for those they’d most like to see. What I like about it is how simple it is:

image

Here you see the three most popular feature requests on their site. Each feature request contains a title, a short description, a category (not shown) and some metadata (in red). Users may vote for and comment on feature requests (in blue). And, Dropbox can update the status of a specific request (in green).

This is the simplest, most elegant site I’ve ever seen for managing a backlog of work. It simultaneously a) houses the backlog, b) tracks feedback, c) gauges interest in competing priorities, d) communicates progress, and e) manages expectations. It’s like a suggestion box that worked out really hard, but never took any steroids. It has all the muscle it needs, without all the bulging veins and other side effects (er, features) of larger sites like Rally.

The only thing I’d be hesitant to do with a tool like this is turn over product decisions to the crowd. What makes Votebox work for Dropbox is that Dropbox has stayed true to their original product vision – a simple, 100% reliable way to backup files to the Internet and sync them across multiple computers. Feature requests outside that vision may be popular, but they would dilute the brand, causing more harm than good to the product.

Rather, I see Votebox as a tool to help talented Product Owners with strong visions for their products interact with their audiences.