Categories
UnitTesting

Spreading Straw

Last weekend, I did one of my “favorite” chores–cleaning up after our two retired greyhounds in the backyard. What does this have to do with programming? Well, shovel in hand, for some reason I started thinking about unit testing. An analogy bubbled and percolated, refusing to let me focus on spotting dog crap.

Our backyard isn’t large, and greyhounds like to run. They’ve devestated any semblence of grass back there, and during Oregon’s wet season (read “nine months of the year”), it’s muddy. Real muddy. To combat the mess, we get bails of straw from the local feed store and spread it all over. Ugly to look at perhaps, but it keeps life an order of magnitude cleaner.
How does this relate to testing? Well, a lot of people talk about getting good code coverage. But even if you get 100% coverage of every path, that doesn’t necessary mean you’ve tested everything.
Imagine each individual bit of straw is a test, while the mud is the codebase. I guess the dogs would be developers then, churning it up, while the rain would be product showering you with requests that threaten to ruin all your beautiful architecture. Hold on, went too far there. Back up to the straw and mud, that’s the important bit.
If I spread my entire yard with straw exactly one piece deep, how well do you think that’d work? We’d have a pit in seconds once the greys got going. Not all parts of the yard are equal. The pit at the corner where water comes down the sideyard and the dogs make a hard turn? That needs some extra covering. How about the main track the dogs have dug down below the walnut tree? The whole length gets more.
I see unit testing the same way. Yes, you should shoot to covering everything, but if you stop at “Tests hit every line of code,” you could be missing something. Where are the more complicated sections? Where should your tests be communicating more of the code’s purpose? Where have your bugs been coming in frequently?
Maybe those spots need a little extra straw.
Categories
ReSharper Tools

Tools: ReSharper

I’ve long been skeptical of Visual Studio add-ins. This goes back to the VS6 days when I fell in love with an add-in, but eventually removed it because it did such horrific things to my machine’s performance. I felt so betrayed, bereft and I’m sure some other suitable words that start with “b.”
Well, times change. WebMD’s been buzzing about ReSharper. It’s been quite a while since I took the plunge, but I’m never looking back.
Enumerating ReSharper features could keep someone blogging for months at the least, but I thought I’d call out a few of my favorites. Seems like half the time someone talks about ReSharper, I find some widget or keystroke I hadn’t noticed before. Maybe you’ll notice something new.
Go to Definition isn’t busted anymore
This one’s kind of a no-brainer, but sometime around VS 2005, I started finding that “Go to Definition” wasn’t working like it used to. It’d bring up strange files with “[from metadata]” in the title, and only give function signatures.
Turns out, as best we can tell, this is because VS doesn’t properly handle the pdb’s on our assembly references. For various reasons we don’t use project references, so for a long time I suffered without my beloved F12.
Well, ReSharper restores this functionality, and it actually works. Now if I could just persuade it to go to code files for projects I don’t have in the solution…
Run unit tests in-context
Prior to ReSharper, I used TestDriven.Net to run my NUnit tests directly from Visual Studio. I can’t tell you how much of a game-changer that was for my unit testing. Good habits often come from reducing the friction of doing the right thing, and having a single keystroke run tests was a massive step forward.
ReSharper provides the same abilities as TestDriven.Net and more. The only caveat is that sometimes it has trouble running large sets of heavy-weight tests (which we have quite a few of around here). For those, I’ll still crack open NUnit itself so I don’t take my IDE down on a long test run.
But for the small tests that drive my design? “Ctrl+R, O” baby, all the way.
Refactoring
I’ve got a confession to make–as big a fan of refactoring as I am, I never quite got up on Visual Studio’s refactoring support. I didn’t have enough time between using VS 2005 and when I started using ReSharper, so I really don’t know what ReSharper’s got that VS doesn’t.
But if you haven’t had the change to work with a refactoring IDE tool, get one, whatever it is. Just the basic rename is worth the price of entry. Again, it’s all about friction, and the refactoring tool makes it easy to revise names when I find later on (sometimes just minutes) that it isn’t quite right.
Move and renamespace are now dear friends of mine. While good naming is important, it doesn’t help if your namespaces are crap, or worse if they don’t align with where to find the code. Not that many years ago this was a difficult problem for us, but now there’s no excuse.
Find Dependent Code
A recent find for me is ReSharper’s brilliant “Find Dependent Code”. This works at a variety of different levels, from individual files, folders and class names, to referenced dlls.
That last one was a huge time-saver as I’ve been winnowing out dependencies from one of our projects before we start some major work on it. Previously, I’ve relied on the grep + break the local compile method to find where a particular assembly was used within a project. No longer. Now all that beautiful information is just a mouse-click away, with line-numbers and double-click-goto support right there.
What else can I say, I loves me some ReSharper!
Categories
Tools

Tools: CLCL

Copy-paste–savior of word processors, “advanced” feature of the masses, bane of software design. Ctrl+C/V is so burned into my fingers that it’s physically painful for me to watch someone clicking the toolbar or menu to copy a piece of text.
But real estate on the clipboard is scarce. Yes, certain applications like Office and Visual Studio provide you with a clipboard ring to save multiple things, but I’ve always found them clunky. Plus, my main use for copying is often bringing stuff from another app, so anything restricted to say, just Word is useless to me.
I’d read about apps that extend your clipboard, but didn’t really pay them much heed until one fateful day. I was writing a new chapter for my book in a web app (which shall remain nameless), and hitting problems. Whenever I’d submit, it was choking. I could click back, and the browser thankfully still had my text. Thinking, “I don’t want to lose what I’ve written,” I copied it into the clipboard. Then I set about trying to fix the app. I shut down the browser (no back anymore), and my speedy little fingers happened to copy another snippet of text–probably a URL or login name, I don’t remember. I’ve blocked it out.
Crap!
Several pages of original text floating in the ether of the clipboard were obliterated. Maybe those clipboard extenders were worth a look.
I’ve settled on CLCL, largely for its simplicity. There’s hardly anything to it, but it will save at least 30 items, crosses reboots, and provides a nice little “save to template” feature where I keep some common strings (login name + domain for instance, since I’m lazy and get tired of typing it into fifteen different apps on our network). Shortcut keys to bring up the saved items completes the picture.
Now I install CLCL anywhere I work frequently. I can’t imagine coding without it there in the background, lovingly gathering up whatever I saw fit to copy, holding it in reserve just in case I need it for later. Thank you CLCL, you’re a lifesaver!
Categories
Tools

Tools: Notepad++

Dealing with text is a huge part of a programmer’s job. While issues of proper design, working with the product requirements, and appropriately testing your code might be more difficult to master, simply navigating massive amounts of code day to day can be a challenge in itself.
Hence, text editors have sparked a million flame wars across the internet. My needs are more modest than the sort of flexibility in emacs or more costly proprietary editors like SlickEdit. I primarily use it for editing snippets of text, cleaning up lists, tracking check-in notes before pasting them into our bug tracking software.
My absolute needs:
  • Fast startup (as close to Notepad as possible)
  • Keystroke macros (learned in Brief on my Dad’s knee and still use those skills today)
  • Regex find/replace
Most of the rest is gravy.
Now why, you might ask, wouldn’t I just use Visual Studio? I’m constantly running it for my main code editing. Well, it clearly fails the first test. Especially when hitting “special” files such as XML and HTML, it bogs down loading up specialized editors I just don’t need. It does have a keystroke macro mode, but it also takes an absurd amount of time to start first time around. That just bugs me. Yeah, I use it, but never happily.
So what is the current winner for my random text editor/formatting/processing? The venerable Notepad++. As the name suggests, it’s a better replacement for Notepad, and it scores on all the points I listed above. Even better, the macro record has the same shortcut key as the same laggy feature in VS. Such symmetry makes my nerdy heart go pitter-patter.
Notepad++ has some other nice features too–some keystroke customization, syntax highlighting, viewing options. My only beefs are no multi-window support (it’s single instance) and the Open File dialog hitting the last opened directory rather than the directory of the current file (a minor detail I just love about VS, and wish was done everywhere).
I’ve also toyed with Notepad2, which was almost equivalent for my needs except the lack of keystroke macros. In any case, if you’re using Notepad still for minor text edits, stop it and give something a little better a try.