TestDriven.NET Keyboard Shortcuts

I’m so sick of Ctrl+Tab’ing back to my test file, finding the test I want to run, right-clicking it with the mouse, and selecting Run Test(s) or Test With.

How come nobody told me that TestDriven.NET came with keyboard shortcuts? They have to be manually mapped, but once I did that, I’ve found them indispensible.

  • Alt+1 : TestDriven.NET.RunTests
  • Alt+2 : TestDriven.NET.RerunWithDefault
  • Alt+3 : TestDriven.NET.Debugger
  • Alt+4 : TestDriven.NET.RerunWithDebugger

I especially love the two shortcuts that repeat the most recent test run for me. Yeah, I know you can right-click in any file and select Repeat Test Run, but if I want to alternate between running inside or outside the debugger, I have to go find the test again. With my shortcuts, I can just hit Alt+2 or Alt+4 no matter where I am.

Splitting CamelCase With Regular Expressions

On my new project, I needed to split a method name up into its constituent parts.

For Ruby programmers, this is easy: just split on underscores. For us .NET programmers, we need something a little fancier since we like to SquashOurMethodNamesTogetherLikeThis.

Here’s a little regular expression that can do exactly that:


That basically says to match right before every capital letter unless the capital letter is at the beginning of the string.

You can use the Regex.Split method to do the actual work of turning the method name into a string array:

Regex splitter = new Regex(@"(?<!^)(?=[A-Z])");
string[] words = splitter.Split(methodName);

My friend, Michael Kennedy, demoed in class recently how to use LINQPad to test regular expressions. It came in really handy while working on this:


I really need to click that “Activate Autocompletion” button so I can give Joseph Albahari the money he deserves for creating such a useful tool.

By the way, I used to think that “camel case” was for words like “camelCase” and “pascal case” was for words like “PascalCase”, but Wikipedia doesn’t make that distinction.

My UnWordify Extension Method

Tim Barcz is looking for a solution to an interesting problem in his Coding Contest: Create a Programming Pearl post.

I decided to challenge myself by writing my solution as a single “line” of code:

public static class StringExtensions
    private static Dictionary<char, char> _charMap = new Dictionary<char, char>
        { (char)8208,  (char)45 },
        { (char)8211,  (char)45 },
        { (char)8212,  (char)45 },
        { (char)8722,  (char)45 },
        { (char)173,   (char)45 },
        { (char)8209,  (char)45 },
        { (char)8259,  (char)45 },
        { (char)96,    (char)39 },
        { (char)8216,  (char)39 },
        { (char)8217,  (char)39 },
        { (char)8242,  (char)39 },
        { (char)769,   (char)39 },
        { (char)768,   (char)39 },
        { (char)8220,  (char)34 },
        { (char)8221,  (char)34 },
        { (char)8243,  (char)34 },
        { (char)12291, (char)34 },
        { (char)160,   (char)32 },
        { (char)8195,  (char)32 },
        { (char)8194,  (char)32 }

    public static string UnWordify(this string value)
        return new string((from c in value
                           select _charMap.ContainsKey(c) ? _charMap[c] : c)

OK, so I cheated and used a dictionary to create my map from the bad characters to the good ones, but the actual method is a single statement.

Hello world! (Again.)

Uh, hello. It’s me again.

I somehow managed to screw up my previous server. I did have backups, but decided that this was as good a time as any to reboot my weblog.

We’ll see how often I manage to post. I’ll try, but I’m not making any guarantees.

Thanks for stopping by!

Verifying JavaScript with JSLint and Visual Studio

Douglas Crockford’s JavaScript: The Good Parts is a short, but informative read that all JavaScript developers should probably pick up. In it, he describes what parts of the JavaScript language we should be using (the good parts) and what parts we shouldn’t (the bad and the awful parts).

To help keep ourselves in check, he’s made his JSLint tool available years ago, but I always found myself too lazy to copy/paste my script into the tool to verify it. I finally decided to make this an almost instantaneous process.

The source code for JSLint is written in, what else, JavaScript. Since I do the majority of my work on Windows machines, I’m fortunate enough to have a built-in scripting engine that can run JavaScript without having to install any extra tools. And, no, I don’t mean my web browser—I mean cscript.exe.

Mr. Crockford does have a simple, cscript-compatible version of his script on his web site. It’s too simple, though. Most of the options it can check are disabled so aren’t checked and it stops after finding its first error.

For that reason, I’ve put together my own “host” for JSLint. It supports the enabling and disabling of all the options listed on the JSLint documentation page with command-line parameters and includes reasonable defaults so that you shouldn’t need to set or unset too many.

I’ve also added an option that adds the global variables defined in the Microsoft AJAX Library so that you don’t have to declare them in each of your scripts or on the command line. I’ve turned that option on by default, but it shouldn’t hurt you if you’re not using ASP.NET AJAX.

It also outputs any errors it finds in a format compatible with Visual Studio. If you set it up as an external tool, you can run it against your current file and hit F8 (the key bound to Edit.GoToNextLocation, by default) to jump to each line an error occurred on. This makes it trivially easy to detect and fix errors. No more excuses for using the bad parts of JavaScript!

To use it, all you have to do is download the latest version of fulljslint.js from the JSLint web site. Put it in some folder in your PATH. For example, I use a folder called C:\Tools to hold the various little tools I find myself needing frequently. Next, download jslint.wsf from this web site and put it in the same folder you put fulljslint.js in. Finally, download jslint.cmd and, once again, save it in the same folder as the other two files. You should now be able to issue a simple command like the following to verify any JavaScript file:

jslint script.js

Of course, to get the most out of using this, you’re going to want to set it up as an external tool in Visual Studio. Open up Visual Studio, go to Tools -> External Tools… and click Add. Enter “&JSLint” as the Title and “C:\Tools\jslint.cmd” (modified to use the folder you actually saved the files in, of course) as the Command. Enter “$(ItemPath)” as the Arguments. Check Use Output Window and click OK.

To test it out, open up any .js file and hit Alt+T and then J (or use the mouse). You should see your Output window appear with the results of the run. If there were any errors just hit F8 to cycle through them.

If you’re confused about why it’s saying such simple things like == and ++ are errors, read Douglas’ book or at least read the documentation for JSLint and the other essays on his web site.

A quick tip for ASP.NET AJAX users: If you register your own namespaces using Type.registerNamespace, you’ll get many errors telling you that your namespace is undefined. Put a comment like this at the top of your file and you’ll be good to go:

/*global YourNamespace*/

Feel free to contact me with any questions or issues you might have. I really want to see us all improve as JavaScript developers so the more people who are using tools like this, the better our code will be.

(a Weblog by Jason Diamond)