Tools

Vil: Dead as in Doornail?

Russell Ball — Fri, 21 Dec 2007 05:49:46 GMT

I spent some time last week working with Vil, a free code analysis tool that can be used to locate potential quality issues and high risk areas in your code. While working on it, I learned all about various code metrics such as cyclomatic complexity, eCouplings, and LCOM (Lack of Cohesion in Methods) and experimented with setting appropriate thresholds for each.

I also incorporated all the required command line switches into our Nant script and even dusted off my XSLT skills in order to create a custom stylesheet to summarize the results and display them nicely on our main Cruise Control report. To my surprise several of the other developers at work seemed genuinely interested in the potential feedback we could get from this tool (people can only get so excited about cyclomatic complexity).

There was one major problem. All the fun I was having was restricted to one small dll. This is because Vil has a built-in limit so that a license key is required when you try to analyze a dll that has more than 100 types in it. The website indicates that all you need to do to attain this license is to send them an email. I did that. Twice. That was two weeks ago and I still haven't heard anything back yet.

Vil is free, so one could argue that I am just getting what I paid for. I guess I figured that since Vil was incorporated into the WebDashboard for CruiseControl, it was established enough to be a safe bet. I was wrong. The last update on the website was two years ago and it was only a vague promise of a new version that would support the 2.0 framework. The new version never appeared and the current version seems to be from mid 2004.

I'm not even sure why the creator of Vil decided to include a built-in limit since the license to unlock it is supposedly still free. Perhaps he had some intention of eventually making it a commercial product or maybe he just wanted to keep statistics on larger customers. If it was an open source project and the source code were available, then I wouldn't mind digging through the code to remove this restriction myself. But there is no source code to be found.

A Plea to the Project Owner: I understand there are plenty of good reasons to abandon a project that you weren't making any money on. However, if you are calling it quits, could you please make one last altruistic gesture and either release the source code or else publish one last version without this restriction? It seems like a lot of work to have spent on an otherwise decent tool only to let it fall into oblivion because of this license issue.

Recommendation to Potential Vil Users: Don't bother investigating this tool unless you already have one of the fabled golden license keys. I'm migrating back to NDepend instead. I've already worked with NDepend and think that it is a far better tool, but I gave Vil a try because it seemed like it would be a lot easier to integrate into Cruise Control due to the built-in support.

Request To CruiseControl Developers: Please remove Vil plugins and stylesheets from the next version of Cruise Control. It's aggravating to spend time getting it to work only to later have to abandon it because it only works with trivially small projects.

OK, Rant complete. I feel better now.

Side Note: Apparently the phrase "Dead as a Doornail" is a very old expression and can even be found in a few of Shakespeare's plays like Henry IV. Based on a quick google search, it appears that nobody really knows why doornails are any more dead than all the other inanimate objects (for example house nails). I saw a few weak guesses, but no explanations that were really compelling. I guess language is as uncontrollable and mysterious as the internet.

Are You Mocking My Code?

Russell Ball — Wed, 19 Dec 2007 06:12:44 GMT

I've been playing around with mock objects using Rhino.Mocks for the last few months, but today was the first time that I had an unfettered coding win and became a true convert.

I was introduced to NUnit about five years ago from a co-worker (thanks Dewayne) and gradually became a true believer. Unfortunately, I was a late-bloomer in the area of mocking, so by the time I finished my last big project I had left a suite of about 500 database driven tests that took almost 2 hours to run and were a maintenance nightmare. The vast majority of my unit testing efforts revolved around SQL initialization and cleanup scripts that massaged the database into just the state I needed for each tests case scenario.

Although this approach definitely made me a wizard when it came debugging data-related production issue quickly, it was too high of price to pay for the benefits I was receiving. Although I remember thinking in the beginning that this "realistic" approach to testing was much more valuable than the "fake" tests that didn't hit the database, by the end of the process I was no longer so sure. I still believed in the value of unit testing, but I knew there had to be a better way of doing it.

During my stint as an architect, I read enough about mocking to know that it was a good idea in theory, but of course I had little opportunity to put that theory to the test. Now that I am a code monkey again, I can say with certainty that mocking is an absolutely essential aspect of Test Driven Development and not simply a "nice-to have" supplemental activity like I assumed before.

Why is Mocking Critical?

It makes debugging easier - When a database driven test fails, the problem could be anywhere and in my experience it is most often related to a problem with the initialization script (i.e. accidental order-based test dependencies). This often led me to ignore test failures when I was pressed for time because I knew that it was likely just another false alarm. However, when a test that uses mock objects fails, I am not only fairly certain that it is a problem with the code rather than the test, but I also know exactly where the problem is because I've guaranteed the behavior of every piece of code except the part that I am trying to test.
It makes writing tests faster and easier - One of the biggest barriers to adoption for TDD for most developers continues to be the perception that it takes too long. I can give a dozen reasons why that perception is wrong, but in the end I think it is more productive to simply find ways to shorten that process. That is exactly what mocking does. Writing out a series of Expect.Call() statements is an order of magnitude faster than trying to write data manipulation statements.
It makes tests execute faster - Don't underestimate the power of fast feedback. Even if you are not a die-hard continuous integration practitioner, you have to admit that the longer your tests take to run the less likely you and other developers will be to actually run them. Even if you do religiously run them at night, the longer feedback cycle dramatically decreases one of the main benefits of TDD, which is the increased coding speed that comes from test-backed confidence and not having to waste time on excessive analysis and fretting about possible unknown collateral damaged.

What does Mocking Require?

Interface Based Programming - If you use Rhino.Mocks, then every class that you mock must implement an interface. With the help of ReSharper, interfaces can be created from an existing class and propagated to the rest of your codebase with just a few keystrokes. This alone makes the price of ReSharper worth it if you are going to start using mocking in a Legacy system that was designed without using interfaces.
Dependency Injection - One of the first stumbling blocks I ran into came from complex collaborations from objects that weren't able to be mocked because they were created inside of methods. You can quickly get around this with a little refactoring by making collaborating objects private member variables and then adding a constructor overload to expose them during testing. It is usually a relatively fast and low-risk design change to make.
Identifying Code Seams - If you find yourself getting frustrated and beginning to think that you are stuck in a code base that is impossible to mock, then stop and read the book Working Effectively With Legacy Code by Michael Feathers. I'm about a quarter of the way through this right now and it is one of the most helpful tech books I've ever read. The author is fearless and infinitely resourceful when it comes to getting code of any language and any quality under test. In fact, many of his examples are in C++ and even C, so that means that you have no excuses when it comes to your own project. He gives lots of practical advice on how to find the "seams", which are the easiest and most cost-effective places to modify code so that you can begin to mock it.

A Practical Example?

Here is an MbUnit test that I wrote today before I tackled a production bug that was assigned to me. It mocks the IPaymentTypeItem, which has read-only properties and thus is normally only allowed to be populated from the database. The Expect.Calls() are just done for the methods and properties calls that are actually made on the object in the piece of code I am testing. You can get a full tutorial with better explanations of the API calls here.

   1: [RowTest]

   2: [Row("%B409999999999999^Russ's Coffee Emporium^09011211000019900000000?;","409999999999999")]

   3: [Row(";4409999999999999=090112110000199?","409999999999999")]

   4: public void Should_Load_Correctly_With_Partial_Track(string trackData, string expCardNumber)

   5: {

   6:     MockRepository mocks = new MockRepository();

   7:     IPaymentTypeItem payment = (IPaymentTypeItem) mocks.DynamicMock(typeof (IPaymentTypeItem));

   8:     Expect.Call(payment.BinFirstDigit).Return(expCardNumber.substring(0,1));

   9:     Expect.Call(payment.IsCreditCard).Return(true);

  10:     Expect.Call(payment.PaymentTypeValue).Return(PaymentType.VisaCard);

  11:     mocks.ReplayAll();

  12:     FinancialCardEncoding encoding = FinancialCardEncoding.CreateCardEncoding(trackData,payment,true);

  13:     Assert.AreEqual(0,encoding.Errors.Count);

  14:     Assert.AreEqual(expCardNumber,encoding.PrimaryAccountNumber);

  15:     mocks.VerifyAll();

Rhino.Mocks is certainly not the only mocking framework out there, but so far I like it because it takes a strongly typed approach rather than relying on strings which means I get to use intellisense. Whatever framework you do choose, I highly recommend that you take the time to learn it well and incorporate it thoroughly into your development as soon as possible.

Friends Don't Let Friends Use the Start Menu

Russell Ball — Sat, 15 Dec 2007 06:35:48 GMT

I've read and listened to Scott Hanselman sing the praises of SlickRun for a long time, but I just recently got around to using it.

For those of you who are as slow to catch on as me, it is essentially just a tricked-out version of the Run window that allows you launch programs much faster than you can through the traditional hide-and-seek start menu approach. This is especially true if you are a tool addict and have a start menu that stretches across your screen.

Best of all, it is FREE, which is one of the few things that still fits into my budget these days. It also only takes seconds to grok and begin saving time with it.

To get started, all you have to do is right-click on the floating SlickRun textbox and select "New Magic Word". When the dialog box with the nifty wizard hat pops up, you simply drag the magic geen lightsaber circled below over to an open program and it will figure out the program's filepath. You can also create the mapping by just dragging a shortcut from the start menu on to the floating SlickRun textbox prompt.

Next, you think of a clever and creative keyword (for example NCoverExplorer for NCoverExplorer) and then optionally assign paramters to it. Parameters are cool because you can do things like open FireFox and surf to your favorite porn site in one swift and efficient motion. For NCoverExplorer, I set the parameter value to the path of the NCover xml result file that gets generated from our automated build process.

Finally, thanks to the magic of intellisense, you just have to type a couple of letters until the keyword you want appears in the textbox and then hit return in order to launch it. Easy, huh?

Just remember, REAL geeks don't use the start menu. If you don't want all the other geeks laughing at you and kicking silicon dust in your face in the computer lab, then I suggest you download SlickRun immediately.

Helpful Configuration Hints

If you're used to Windows-R to launch programs, you can change the default SlickRun hotkey (Windows-Q) to this more familiar one by setting GrabWinR=1 in the slickRun.ini. You can find this config file in your computer's app data directory (directory locations vary based on the OS), but it won't actually be created until you close SlickRun for the first time.
I also like turning the ChaseCursor option on so that launcher window pops up where ever your cursor happens to be after hitting the hotkey combination. This saves me from having to shift my focus to a different part of the screen... Yes, I know that it seems lazy beyond words to recommend a feature just because it saves my eyeballs from having to move a few centimeters.

Notes about Vista

SlickRun is not quite as compelling on Vista because of the built in launcher in the Vista start menu. However, I still like using it on Vista because it offers more flexibility in terms of creating more logical words for program names as well as automatically passing in parameters to the program.
Setting up magic words by dragging shortcuts from the start menu to the SlickRun prompt doesn't work on Vista for some reason.

Interesting SlickRun Factoid

This was actually written in Delphi. I'm going to let you come up with your own Delphi jokes so as to avoid any hate mail from either one of the remaining Delphi programmers out there.

A Touching VSS Moment

Russell Ball — Fri, 07 Dec 2007 05:41:05 GMT

Today it was decided that a bug fix that I recently added to our production branch in Visual Source Safe would not be included in an upcoming hotfix release as originally planned, so I was asked to remove it.

My fix only touched 6 files, so my first thought was just to do it manually. Then I saw the rollback button in the 'Show History' window. If I were a betting man, I would have put good money on this functionality not only failing, but also wreaking havoc with our version history. However, I was feeling strangely brave today so I held my breath and clicked the button anyways.

Contrary to all expectations, it actually worked. It erased the historical records that came after the version I rolled back to, but since I already had those changes merged into the mainline I was in a forgiving mood and considered it an unfettered success.

In fact, I was so pleasantly surprised that I started to utter what might have been the first positive words about VSS that ever came out of my mouth. However, before I could finish my sentence I was greeted with this response.

I guess VSS was verklempt due to my kind words. Either that or it detected the ever so subtle note of sarcasm in my voice and closed in a huff. Truth be told, I don't think it ever forgave me for the poem I wrote about it several weeks ago.

I bet SubVersion is not this sensitive to criticism.

A Couple Firefox Add-On Gems

Russell Ball — Sat, 17 Nov 2007 18:21:15 GMT

This week I installed a few nifty Firefox Add-Ons, All-In-One-Gestures and IE Tab.

I tried All-In-One-Gestures after watching how fast a co-worker was able to navigate on the web by using this Add-On. It allows you to right-click anywhere on a web page and move the mouse left to go backward or right to go for forward.

Navigating this way is definitely much faster than using the browser toolbar buttons and helps me stay in a better flow when trying to quickly scan oodles of google results.

For some reason I also really like the little red line affect that shows up on the page, but I'm easily impressed like that.

The other Add-On, IE Tab, lets you view how a web page will be displayed in Internet Explorer by simply clicking on a button at the bottom of the page. This came in handy when I was trying to figure out why a Cruise Control report generated by FxCop was not working. On a hunch, I toggled to IE and realized that the XSL had browser compatibility issues because it worked fine in IE. It was nice to be able to verify this by simply toggling view modes rather than having to start a different browser and then navigate to the page.

The moral of the story: Always pay attention to how your co-workers do things. I don't think I ever met somebody who didn't have at least one time saving tool or trick up their sleeves that I could steal to my great benefit. I like to think of every productivity enhancing tool or technique as a little investment. It may take a little "seed money" in terms of time and effort, but it is amazing how quickly the dividends begin to pay off so that my overall time savings quickly surpasses my initial investment.

EditPlus: A Kinder, Gentler Way To Build Nant Scripts

Russell Ball — Fri, 09 Nov 2007 02:06:36 GMT

I've been working on Nant scripts this week and the experience has been much more enjoyable since a co-worker showed me how he used EditPlus (thanks Raoul). After a few quick customizations, I was able to not only get syntax highlighting for my build files but also execute Nant from within the tool and see the output from the bottom pane. Anything that decreases context switching when I have a gajillion windows open is pretty nifty in my book.

Here's a picture of a build file with my custom button circled at the top and the nant output in the bottom pane..

Here are a list of tweaks that I made:

For syntax highlighting:
1. Under the Document menu, go to 'Change File Type' and select XML.
To create a custom button that will execute the build you are editing:
1. Select 'UserToolbar' under the View menu to get the user configurable buttons to appear.
2. Click on the first button (the hammer icon) of the user toolbar that appears and choose 'Configure User Tools'.
3. On the dialog box that appears, click the 'Add Tool' button and select 'Program'.
4. For the Command field, navigate to the location of your Nant executable.
5. For Argument field, enter the buildfile argument (-f:) and then choose 'FileName' from the drop down so that the name of the current build file you are editing will dynamically be sent as a command line parameter.
6. For the Initial Directory textbox, choose 'File Directory' so that the path of the current file will be dynamically sent as a command line parameter.
To view the output from Nant in the bottom pane:
1. Click on the 'Capture Output' checkbox from the previous dialog box.

In order to execute your Nant script, simply click on the first button that becomes enabled on the user toolbar. This is what the dialog box looks like for the above steps:

Happy Nant scripting!

A Poetic Tribute to Visual Source Safe

Russell Ball — Thu, 08 Nov 2007 06:03:05 GMT

Recent source control woes have inspired me to write this little poem about my least favorite source control system.

VSS, I hate you so
And I can not wait to see you go.

You have the word safe in your name
Yet since you came
my IDE has crashed
And my files have been trashed.

If your integration were not so lame,
Then maybe I could do a simple rename;
All I wanted was a little bit of history
But a few files I did purge and now it's all a mystery.

Branching and merging is something we no longer dare
So we copy and paste with much care;
A changeset would help reduce the friction
and make release reports seem less like fiction.

If only you would realize
that it should not take days to Analyze;
And it is wrong that I should have to be leery
when all I want to do is a simple query.

Because of your file based sharing
About disk space and security we gave up caring;
Haven't you heard of atomic commits?
If so, perhaps my project wouldn't be on the fritz.

If only I could create a simple diversion
Then I could quickly upgrade to Subversion.
Perhaps if we had Perforce or Vault
Then our development wouldn't grind to a halt.

VSS, I hate you so
And I can not wait to see you go.

For a non-rhyming look at some of the short-comings of VSS, I recommend this article by Alan de Smet.

Still an Open Source Virgin

Russell Ball — Tue, 06 Nov 2007 14:10:59 GMT

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.

The Resharper Challenge: What if You Could Only Have 7 Features?

Russell Ball — Tue, 23 Oct 2007 05:28:38 GMT

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)

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

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.

Identifying Dead Code (text colored gray): No more excuses for letting unused code clutter your code base.
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.
Rename (F2) - This is a LOT smarter and quicker than the Visual Studio Find & Replace.
Find Usages (Shift + Alt + F12) - This also beats the pants off of Find & Replace for doing impact analysis.

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?

In Praise of MbUnit

Russell Ball — Fri, 19 Oct 2007 22:22:34 GMT

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.