Caffeinated Coder

I was setting up Cruise Control the other day and trying to figure out why it wasn’t working on a certain source control folder. I noticed a strange error in the cruise control log about there being an invalid character in the path, so I decided to take advantage of the fact that it is an open source project and download the source code so I could step through it in the debugger and see what the exact problem was.

It wasn’t long before I discovered the source of the error, which was a newline character embedded in the source control folder name. Since I am a vocal Visual Source Safe hater, I naturally assumed that the problem had to do with VSS data being corrupted so I scheduled some VSS maintenance and called it a day.



When VSS analyzer did not fix the problem, I took a closer look and realized that I had unfairly blamed VSS and the real problem was a bug in the Cruise Control code that parses out the output from the VSS command line tool (thank god PowerShell eliminates the need for much of this parsing voodoo). If the folder path in VSS is too long, then the command output wraps and Cruise Control incorrectly inserts a newline character inside the folder path.

The problem was easy enough to fix by stripping out the rogue newline character, so I recompiled Cruise Control, replaced the problem dll, and all was well in the world.

At that point, it occurred to me that other people must be running into this problem, so I decided to try being a good open source citizen for once and submit the bug fix. I had never tried this before, so I read the contribution procedures posted on the home page and followed their polite suggestions. I created a diff file of my fix, wrote up a detailed description of the problem, and even found a unit test that someone had commented out that failed under the current code base and worked with my fix.

I was just about ready to submit a JIRA ticket in their bug tracking system, when it occurred to me that I should probably browse the current VSS tickets first. It turns out that my issue was not only recorded in the system, but had just been marked as resolved by someone else the week before. Doh! I guess I should have tried that first, huh?



Oh well, at least I got practice going through the procedure for being an open source contributor. There are still an lots of open tickets for the current Cruise Control release, so perhaps I’ll grab one of them while I have everything already set up.

After all, I don’t want to be an open source virgin forever.

I was working with someone who doesn’t have ReSharper today and I noticed for the first time that I have developed some feature addictions because I actually winced when I watched him fully type out a property and then manually do an “extract method” refactoring.

This surprised me since I have only really been consistently using ReSharper for the last month and am still far from my goal of becoming a ReSharper Jedi. Nevertheless, the dozen or so keystrokes that I have mastered and consistently use are making a noticeable difference in removing some of the coding noise that usually distracts me and slows me down while coding.

In keeping with the lucky seven theme from my last post, I decided to share seven favorite features. In other words, if there were suddenly a terrible ReSharper feature shortage and the Programming Gestapo started forcing everyone to ration their features, this is what I would choose.

(NOTE: All shortcut keys are according to the VS Bindings)

1. Auto-inserting using statements (alt + return at prompt) - This is by far my favorite feature. How does it know what I wanted so quickly?



2. Generating properties, constructors, & overrides (Alt + Ins) - For properties, it lets you choose from a list of private variables without properties. For constructors, it lets you choose from a list of possible properties to use as parameters.
   




3. Identifying Dead Code (text colored gray): No more excuses for letting unused code clutter your code base.
   
4. Extract Method (Ctl + Alt + M) - It figures out which parameters you’ll need to pass in and replaces the highlighted text with a call to the new method.
5. Rename (F2) - This is a LOT smarter and quicker than the Visual Studio Find & Replace.
6. Find Usages (Shift + Alt + F12) - This also beats the pants off of Find & Replace for doing impact analysis.
   




7. Go ToType (Ctl + N) - I like how it pops up at my cursor, filters the list while I type, and shows the location of the files.
   

I fully expect this list to change as I get more proficient with the tool and as I start working on a 2.0 .NET project instead of a 1.1 project so that I can use the latest version of ReSharper.

Which seven features would you choose? If you had to recommend one killer feature that I am missing out on, which one would it be?

I’ve played with MbUnit before and was immediately impressed, but I haven’t tried using it on a project until today. I was surprised by how quickly and easily I was able to convert all of my NUnit tests. All I had to do was switch the references from NUnit.Framework to MbUnit.Framework and then do a quick find and replace for my using statements. After that everything magically worked. Kudos to the MbUnit team for not pulling an ‘MSTest’ move and renaming all the attributes and keywords.

Best of all, I was able to add several new tests quickly by simply adding parameters to my test methods and then using the MbUnit Row attribute to dynamically pass in multiple values. This simple feature not only helped eliminate quite a bit of duplicate test code, but it also encouraged me to exercise my code with more test data which immediately led me to find some new bugs.

I especially like how the MbUnit test runner lists each parameter as a separate test so you can easily see which one of the data elements caused the problem. It’s also nice to have multiple views of the test at the same time (Author/Category/Namespace).

If you haven’t already tried using MbUnit, I highly recommend it. There is almost no effort involved in learning to use it, especially if you’ve ever used NUnit.

If you work with PowerShell and don’t already have PowerTab installed, take a few minutes to download and install it now. It’s a painless setup, especially if you just keep hitting enter at the prompts to accept the defaults, and the ansi-art intellisense magic just starts working everywhere without you having to learn anything.

If you’re still not convinced, take a minute to watch this quick flash demo. I made the mistake of thinking that I had to master the basics in PowerShell before experimenting with extensions and specialized tools so I didn’t install it until recently and I am still kicking myself. You will definitely make PowerShell your b**ch much more quickly if you just install this from the start.

As an aside note, this is yet another example of how much a single talented geek with a good idea can accomplish. The Mark van Orsouw (a.k.a /\/\o/\/\ or The PowerShell Guy) has definitley joined the ranks of Lutz Roeder (Reflector), Patrick Smaccia (NDepend), Roy Osherove (Regulator), Jamie Cansdale (TestDriven.NET), Ayende Rahien (Rhino.Mocks), and countless other tool developing cowboys in the geek hall of fame. Now if only more women would throw their undergarments at famous developers, perhaps I would have the final motivation I need to start working on a cool developer tool or add-in of my own.

As a double aside, there is simply no good comeback when your wife asks you why you are so interested in another man’s tool.

In my recent post on code quality, I mentioned some of the high level features of a static analysis tool called NDepend. I’ve been exploring some of the pre-built CQL (Code Query Language) queries in the tool by running them against the WatiN codebase. Here are the results from selecting “Types with Too Many Methods” query. NDepend shows you a list of the classes and number of methods in each on the left along with a visual Tree Map visual representation on the bottom. 

Once code is analyzed while first loading the assembly, the GUI is blazingly fast and dynamically updates whenever you highlight a new query. You can modify queries to suite your own standards and then double click to drill into the exact spot in the code. Here is what the CQL query looks like for identifying types with excessive methods:

WARN IF Count > 0 IN SELECT TOP 10 TYPES WHERE NbMethods > 20 ORDER BY NbMethods DESC

Here are some other pre-built queries that I found especially compelling:

1. Methods too big ( > 30 lines of code)
2. Methods with too many parameters ( > 5)
3. Too many local variables ( > 15)
4. Methods too complex (cyclomatic complexity > 20)
5. Poorly commented (% comment < 20 and # lines > 10)
6. Fragile base class (depth of inheritance > 6)

NDepend showed that WatiN had the following issues that could potentially be refactoring opportunities.

1. One method with too many parameters (SendMessageTimeout has 7)
2. Ten classes with too many methods (Document has 97)

There are also a very helpful group of queries that are designed to just help you better understand the codebase by identifying the most used methods, types, and namespaces.

As an interesting aside, this tool seems to have been written entirely by one person, Patrick Smaccia. I want to personally thank him for giving me indisputable proof that I barely qualify for a bottom-dwelling, plankton-like status on the alpha-geek food chain.

Monitoring and enforcing code quality seems to be somewhat of a holy grail in the software industry in that nearly every development shop pursues this goal but few ever even come close to actually achieving it. Here are a few of the common failed approaches I’ve seen:

• Developer’s Handbook - Despite being a darling of auditors, I find this approach to be a largely worthless exercise for anyone except perhaps the author of the document. Like all waterfall-based functional specifications, these documents quickly become outdated and are seldom read and often misinterpreted by developers. Even in ideal circumstances where developers are highly motivated to follow guidelines that are well understood, this honor system approach falls hopelessly short simply because of basic human fallibility. Logical mistakes in code are caught because users, testers, or unit tests complain about something not working, but how are code quality mistakes caught?
• Code Reviews - After becoming disillusioned with the honor-based rules approach, many shops attempt to supplement their developer handbooks with a manual code review process. Although a second set of eyes increases the odds of catching errors, this approach is extremely expensive to implement and subject to all sorts of emotional pitfalls that can easily turn the review into either a meaningless rubber-stamping exercise or an ugly battle of egos. Even with the most mature and disciplined developers, this approach ultimately fails to provide the level of code quality that shops are seeking due to a lack of knowledge or simple oversights by the reviewers.
• Architects - In order to maximize the effectiveness of reviewers, shops might take the step of designating a specialist, such as an architect, to be in charge of overall code quality. Unfortunately, whatever advantages that this position brings to the review process in terms of technical knowledge and increased authority are often nullified by the specialist being too far removed from the code to appropriately identify issues or too far removed from the team to effectively enforce changes. Even when the specialist is viewed with respect rather than ridiculed as an out-of-touch Architecture Astronaut, suggestions tend to be seen as too subjective to be actionable when compared to hard deadlines.

Now for some more promising options that I’ve seen…

• FxCop - This tool analyzes source code and produces a list of violations where code doesn’t comply with a set of preconfigured rules, such as naming standards. By relying on software rather than people to enforce code quality rules, you dramatically decrease the chance for error, the perceived subjectiveness of the process, and the overall cost. Unfortunately, static analysis tools such as FxCop are only capable of monitoring a certain class of the more superficial rules and don’t catch logical errors or help identify more complex code quality issues such as cyclomatic complexity, low cohesion, excessive dependencies, or overly complex interfaces.
• NDepend - This static analysis tool picks up where FxCop leaves off by providing visualizations and SQL-like code querying capabilities to identify the areas of the code that suffer from low cohesiveness, excessive complexity, and inappropriate dependencies. More importantly, it provides a big picture view of a code base that allows developers to identify and prioritize issues with the entire code base rather than just issues pertinent to the particular piece of functionality being implemented. This allows someone like an architect to effectively analyze a code-base without having to be intimately familiar with all of the details and provide objective evidence to backup any recommendations for making changes to the code.

Although I firmly believe that static analysis tools provide the most cost effective gains in code quality and should form the first line of defense in any shop’s quest for code quality, I do think that manual reviews should still figure into the equation. Tools will never be able to verify whether code is soluble or that code logically satisfies the user’s intent or that IT shared assets are effectively being utilized. I even think that a Developer’s Handbook can provide value as long as it remains a living document that offers light-weight guidance rather than trying to exhaustively cover low level details that are ultimately technology specific and subject to change.

For anyone interested in learning more about NDepend, I recommend starting with this old Hanselminutes podcast followed by this quick 3 minute online demo of the code querying language in NDepend. Expect more posts from me on this most excellent tool in the near future.

I used Resharper’s unit-test runner for the first time while spelunking WatiN last week and quickly became a fan. If unit-test runners were high school boys, here are a few reasons why the Resharper test runner would be dating the entire cheer leading squad while the NUnit test runner would have to bribe a distant, homely cousin in order to get a prom date.

• Integrated IDE experience: I think NUnit is good for deployment scenarios when you just want to load the test dll and verify the environment, but using a unit-test runner that is not integrated into the IDE is too frustrating for me when it comes to normal development. I used NUnit exclusively for several years, but I’ve been too spoiled by TestDriven.NET, SharpDevelop, and even MSTest to want to waste any more cycles switching between applications.
• Navigation between Tests and Code: Resharper lets you run tests by right-clicking anywhere in the test code (similar to TestDriven.NET) or by clicking on the ’gutter icons’ to the left of the code window. You can navigate in the other direction by simply double-clicking on the test icon, a feature I often use when investigating why tests fail.
• Ad-Hoc Test Groupings - The only way to organize groups of tests that can be run together in NUnit is through namespaces. This works fine for groupings that you could plan out ahead of time such as fast-running vs. slow-running tests or tests that share common dependencies. However, if you do have to run tests from different namespaces in the NUnit GUI, the only way to do it is to highlight and run one test at a time (you can’t even use the ctl-click option to highlight multiple tests). MSTest made a step in the right direction with their test list by allowing you to simply drag tests from different namespaces into a list, however Microsoft made the mistake of only including this feature in the Team Suite edition (which costs $10,000 plus an primary appendage) and also only allowing a test to belong to one list at a time. Resharper solves this issue by allowing you to add any test to a Test Session and also by implementing the Ctl-Clicking functionality to highlight multiple tests. There are also filter buttons on the toolbar that allow you to do things like only rerun the tests that failed.
• Test Validity Status Monitoring: If you have changed and rebuilt your code without rerunning your tests, little question marks appear over the red/yellow/green icons. Depending on the size of the project and your use of shortcut keys, rebuilding can become an automatic reflex like saving a document so it’s nice to get a smart reminder about whether or not your last test results are still valid.

Let me conclude with a disclaimer that I am primarily talking about the best way to run test written with the NUnit framework. When choosing between frameworks, I am now an advocate of MBUnit for reasons I’ll outline in a future post. 

Several weeks ago I used WatiN (pronounced as What-in) to create a suite of automated GUI tests for an old internal ASP application that we were upgrading. Inspired by the popular ruby testing tool Watir, WatiN is an open source .NET wrapper around the Internet Explorer that you can reference in your test project and use to get access to all of the HTML elements on a web page. I was surpised by how easy it was to simulate a user typing text and clicking buttons and then check to see if the result page contained certain text. The following popular example code demonstrates how you would test a google search for WatiN.

[Test]
public void SearchForWatiNOnGoogle()
{
 using (IE ie = new IE(”http://www.google.com”))
 {
  ie.TextField(Find.ByName(”q”)).TypeText(”WatiN”);
  ie.Button(Find.ByName(”btnG”)).Click();
  
  Assert.IsTrue(ie.ContainsText(”WatiN”));
 }
}

Today, I experimented with the IEDevToolbar for the first time and suddenly WatiN became much more compelling. By using the “Select Element By Click” feature under the Find menu in the IEDevToolbar, you can simply click on an element on a web page and instantly see all of its properties. Since most popular commercial sites have very large, chaotic source files with elements that don’t always have ID or Name properties, this feature is indispensible when trying to figure out how to programmatically interact with the page. Below shows how I was able to retrieve the Starbucks stock price from CNN and create a test to ensure that it was above an acceptable amount.

Since the stock retrieval button on cnn.com was an image that had no name or ID, I used the Find.ByCustom() method to retrieve and click on the button using the className attribute.

This task would be even easier using the WatiN Test Recorder, which you can see in this flash demo. However, I still haven’t been able to get the recorder to work properly on my Vista machine so I’m not a big fan of this tool yet. I will definitely keep an eye out for future versions though.

I’ve finally been bitten by the Resharper bug and now I want to be a Resharper Jedi when I grow up like Ilya Ryzhenkov on this video. According to the JetBrains .NET Tool Blog, a Resharper Jedi is someone who “can code hella fast with ReSharper and blow productivity levels off the chart”. I haven’t heard any claims about Resharper being able to help me Jedi-mind-trick my way out of traffic tickets, but there sure is a lot of reverent blogosphere speak about people like Ayende who can code at the speed of light during demos thanks to his mastery of this tool’s navigation, code generation, and refactoring keyboard short-cuts.

I just finished reading Joe White’s 31 days of R# and trying out almost every item in the Resharper menu that appears in Visual Studio after installing it. So far the force does not appear to be as strong in my family as I had hoped, but with luck I will make steady progress in the near future with the help of the Resharper Cheat Sheet, which I plan to post up on the wall of my new cube.

Below is a screen shot of one of my favorite features, the Usage option (Shift + Alt + F12 under VS Bindings). It shows all the references to the selected method or property, which is great when you are trying to determine potential side affects of changing legacy code (assuming you don’t already have a ton of unit tests to assuage your fears).

I’m doing some work now on an internal web application where I had to logon with an external test account before I could do anything. That got old fast, so I created a powershell script file to automatically launch IE, input the username and password, and click the submit button. I originally tried to do this with WatiN, which provides a much easier interface for controlling the browser than the COM object InternetExplorer.Application, but I couldn’t get by the security exceptions explained in this Scott Hanselman post. I then added a keystroke shortcut in WinKey to execute this ps1 file via the hstart utility so that no command window would flash on the screen before the browser window could load. It’s probably not the cleanest solution, but it has been a huge time and annoyance saver.

Here’s the winkey info

command: <>\hstart.exe
parameters: /nowindow “C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -command “”&”  ‘C:\myScriptsDirectory\launchWebApp.ps1′”"

…And the powershell script

$psie = new-object -com InternetExplorer.Application
$psie.Navigate2(”http://www.someWebApp/”)
$psie.visible=1
($psie.document.getElementsByTagName(”input”) | where { $_.Name -eq “UserID”}).value = “userID”
($psie.document.getElementsByTagName(”input”) | where { $_.Name -eq “Password”}).value = “password”
($psie.Document.GetElementsByTagname(”input”) | where { $_.Value -eq “Login”}).click()