Article on Selling Developer-Level Testing

I wrote an article on successfully selling developer level testing in your organization for nPlus1. The article hits a lot of things I think are really important when talking to your management and team about implementing some form of developer testing.

You really do need to make sure you present an honest, well-thought case for testing before rolling in to it. Hopefully this article will help you if you’re searching for ammunition to help win that debate!

Go read it. Then go write some tests.

Video: Panel Discussion on “Drinking From The Firehose”

I was flattered to be asked to sit on a lunchtime discussion panel at last month’s Ann Arbor Day of .NET. David Giard moderated the discussion and Aydin Akcasu captured it all on video.

Dave’s posted the video on his terrific Technology and Friends site, and it’s well worth you spending 37 minutes to watch it. Not because I’m on the panel, but because the discussion covered a lot of things I’m especially passionate about.

Some of those things would include, in no specific order:

• Technology’s moving fast, and coming in waves – but we’re empowered to do so many more things than we were even five years ago. I can focus on delivering value instead of writing infrastructure or tooling.
• Companies need to invest in their workers’ training.
• Workers need to get emphatic about owning their own careers. Companies need to support them, but you, not your company, own your destiny.
• Managers need to support workers with time sliced out of the schedule for continuous, ongoing training. (I didn’t even ask permission with my management. I just directed my team to take two hours a week and go explore. That’s my job as a boss: get forgiveness instead of permission…)
• Not learning every new shiny thing is OK. Maybe learn something about what biz value new technologies offer, but carefully pick and choose what you’re willing to dive in to.
• Do spend some time exploring new things, though, because that learning will inform and impact how you work with your current technology.

Props to Dave for a great show, and thanks to fellow panelists Mike Eaton, Jay Harris, Patrick Steele, and Jason Follas. It was a pleasure being up on stage with y’all.

Slides & Demo Solution for Selenium Test Presentation

I’ve uploaded a zip with the slides and demo code from my “Web Testing with Selenium” at Saturday’s Central Ohio Day of .NET. You can find them here.

The zip is 16MB in size – sorry, but that’s including the 15MB Selenium v1 jar file. There’s a README file in the root explaining the solution and some of the various support files.

If you attended the session, thanks! I enjoyed talking about Selenium and hope you got some good info.

Exploring Selenium 2: Introduction & Lessons Learned in Selenium 1

We use Selenium (version 1.x) at work as a regression / functional test tool. We’ve gone through a number of iterations over the last year and a half since I first started pimping Selenium and learned some valuable lessons. Now we’re in the process of migrating to Selenium 2/WebDriver and I’ve been really pleased with the results so far.

I thought I’d write a short series of short articles showing some of the things we’re learning about Selenium 2 / WebDriver.  To kick off the series I thought I’d lay out an overview of the journey we’ve taken so far, and some rationale why I knowingly chose a less-than-optimal solution at the start.

First, a quick overview of the bits and pieces of Selenium v1, the toolset we started out with:

• Selenium IDE (SIDE): A Firefox plug in that lets you record browser actions (navigation, clicks, input) and play back those. You can write assertions to check for things like text, elements, etc. Scripts can be saved out as HTML or exported to Java, Ruby, C#, and a few others. You can write your own templates for outputting scripts.
• Selenium Remote Control (Selenium RC): A Java-based server app that launches, manages, and kills browser sessions. You start up RC, then run tests written in one of the various supported languages (lots of client libraries around), and RC does the rest. RC lets you run your tests against different browser platforms. If your scripts are simple, you can run one test suite against Firefox, IE, and Chrome without re-writing. Theoretically…
• Selenium Core: This is the basic framework for both SIDE and RC. When you spin up RC you’re getting core as part of the environment.
• Selenium Grid: Manages splitting off test suites to run your tests in parallel, thereby massively speeding up your tests. (I haven’t used Grid.)

Initially we started out using Selenium IDE, the record and playback tool, for writing our tests. Some caveats should be noted about our test goals: we were building out automated test suite from ground zero and were focusing on very fundamental, simple functionality tests. Think CRUD operations, navigation confirmation, etc. No fancy UI manipulation, no dealing with Ajax or Javascript. With this in mind, we could use SIDE and save off the scripts as HTML files and feed those to RC. This approach had some pros and cons.

Pros:

• At the time, our Program Managers were our primary testers. SIDE’s record/playback made it easy to get some tests written. ( Some tests > no tests)
• HTML based scripts made it easy for folks writing tests to alter the scripts as needed because SIDE’s recording actions didn’t deal well with dynamic content or a number of other things. We’d have to clean all that up manually.
• RC takes HTML scripts as an input, so we could automate what tests we were able to come up with.
• HTML files are easily wrapped in to our source control system. Treat your tests like production code, because they are production code. Get your test files, regardless of format, in to your source control. Go on, I’ll wait here while you do it.

Cons:

• Record and playback tools are generally failures for anything above a trivial one-off script. The tools create fragile, wonky scripts which require a lot of tweaking to get right and more tweaking to maintain. (Yes, yes, yes, you may have had glorious success with tools from Rational or Mercury. 99% of the rest of the testing world can’t afford the hundreds of thousands of dollars for those tools.)
• SIDE and Selenium don’t do well with relative links in their HTML files. This made it impossible to centralize common functions like logging in to and out of the system, creating users, etc. This is perhaps the biggest strike – if ANY link changes anywhere, you’ve got to fix up every occurrence of it. Massive violation of DRY, massive fail.
• Managing Selenium RC’s server app during a build cycle can get tedious.
• RC turned out to be even more finicky with timing issues around scripts. Any web UI script is already very sensitive to timing issues around your page loading and rendering. HTML scripts were even more so.

I’d known about some of the SIDE limitations going in to the effort; however, I needed something that would be a quick win to show how functional tests could help the entire team. We had some great success with those initial tests, but I had always wanted to push to “real” Selenium tests via Ruby or .NET. I knew we’d have much better results, and it was also a way to get me back in to writing code on a regular basis. (Cue evil mastermind’s laugh.)

Making the case for moving to code for our Selenium was greatly simplified because I’d show the value prop of test automation already. We’d caught a number of regression bugs simply through the automation tests chugging away and finding things like “Whoops. The logon link isn’t on the main page anymore…” Sometimes you need to start really small and get a few victories on the board before pressing on to the better solution.

With all this in mind, I started writing Selenium tests using the .NET libraries and running those via RC. I started a migration path converting the old HTML tests to C#-based tests and passing those off to RC for execution. More pros and cons:

Pros:

• I get to write real code. I’ve been in a Practice Lead, Program Manager, or Quality Lead for several years now and haven’t been able to crack open Visual Studio but once every few months. Writing code makes me very happy, so quite frankly I’m not ashamed to list this as a pro.
• Using a “real” language to write tests instead of HTML scripts lets us start to build up a common library for frequently used calls. I can centralize things like log in / log out, content creation, etc. (I’m not centralizing tests for those steps, mind you, just the actions which might be prerequisites for other tests.) Building up infrastructure/an API for your test environment is critical to your success – speed, maintainability, readability, the benefits just go on and on.
• I can now use a languages tools like iterators, branches, etc. to start writing much more powerful tests and support functions.
• Did I mention I get to write real code again?
• Tests in native code run through RC are much, much more stable and performant. We saw a significant reduction in false failures and tests ran faster.

Cons:

• Your tests are now in real code. If you were hoping to leverage non-coders to help write your tests then you’ve cut off that resource. Now you’re looking at finding time from your dev team to write your tests, or you’re looking at finding QA resources who can write code well enough to write your tests. (I found a great one of the latter. No, you can’t have her.)
• Selenium RC is still in the picture. You have to spin it up, and you have to deal with false failures injected into your tests due to RC being the middle man broker.

At this point I’d been fortunate enough to get another couple full-time, dedicated QA resources on board. This gave me the flexibility to start looking at other tools. Based on a couple comments from Jeremy Miller and Adam Goucher I decided to look in to Selenium 2.

Selenium 2 is combining with WebDriver, a nifty pairing that lets you get rid of having to deal with the separate Selenium RC server and directly manipulate the browser. Less moving parts is a huge win in my book. The API is a lot cleaner, much more readable, and solves a number of technical issues around timing. The tooling is officially in “Alpha” status; however, it’s quite full-featured already and quite stable. We’ve been having great success with it so far.

I’ll follow this introductory post with several others walking through our move from Selenium 1 to Selenium2/WebDriver.

MSBuild: Targeting a Configuration from the Command Line

Update: Read the comments for some good tips from other readers.

Firing up Visual Studio to simply build a solution is nuts. Do it from the Visual Studio Command Prompt instead and save yourself time.

What I always forget, though, is how to specify a release build, ergo I’m writing this blog post so I can quickly find it the next time I need it.

From the command line, use the “/p:” switch and pass the value “Configuration=Release” like so:

msbuild CommunityServer.Sync.sln /p:Configuration=Release

I’m also in the habit of first doing a clean build before the release build to ensure I’ve got no leftover cruft:

msbuild CommunityServer.Sync.sln /target:clean

(Actually, I tie all this stuff together with SlickRun shortcuts and batch files, which is even better!)

Central Ohio Day of .NET is Soon!

This year’s installment of the Central Ohio Day of .NET is coming up soon! This year’s event is just a couple weeks away on 5 June. We’re returning to the handy Roberts Centre in Wilmington, nicely located equidistantly between Dayton, Columbus, and Cincinnati.

If you haven’t already, go have a look at the terrific session list, then go register.

We’ve had great turnout for each event – last year’s was over 200. If you don’t go you’ll be missing a terrific opportunity to improve your skills and network with your peers!

Wrap up From Ann Arbor DODN

I spent Saturday at the Ann Arbor Day of .NET. Jason, Scott, John, and everyone else involved once again put on a tremendous event. It’s one of the region’s best conferences and was absolutely worth driving up and back on Saturday.

I gave two talks and was flattered to be part of a productive lunch-time panel discussion on how one keeps abreast of the huge amount of technology that floods we geeks.

You can find the slides from my “Three Tips to Improve Your Development Process” talk here. Apologies to everyone who attended that – thanks very much for putting up with the system crash I had. (For those who weren’t there, PowerPoint completely, absolutely froze up. Rather than lose five or ten minutes restarting my entire system and trying to reset back to where I was, I just pressed on with the talk sans slides. I’ve given the talk enough times that I was comfortable with speaking to a few things I scratched out on the whiteboard.)

During that talk I made reference to a number of things:

• Shore and Warden’s The Art of Agile Development. Awesome book on so many levels. I’ve adapted my current retrospective format from it.
• Derby’s Agile Retrospectives. An entire book on retrospective goodness!
• Etherpad.com or Titanpad.com. Awesometastic online real-time collaboration tool for taking notes. I use this on a daily basis with my offshore folks.
• Twiddla.com. Online whiteboard. It’s awesome. I blogged earlier about doing retrospectives using this tool.

The deck for my “Leadership 101” talk isn’t really going to be a lot of interest to anyone. After all, it’s 14 slides total, one of which is blank, two being single pictures, one title slide, and the other slides having only one word apiece on them… The title slide has more words on it than are in the rest of the entire presentation. Go figure.

However, I did mention a few things I thought were useful for folks looking to learn more on leadership.

• The Leadership 101 series I wrote which fired me up to do this talk.
• D-Day from Stephen Ambrose. This, along with his work Citizen Soldiers, give you some amazing insight to the generation that fought WWII. You’ll learn about high-level leaders like Eisenhower and mid- and low-level leaders in the foxholes at the front lines.
• Band of Brothers, also by Ambrose. More amazing stories, this time centered on a company of soldiers who were in the entire European campaign.
• Ricardo Semler’s Maverick. Mind-blowing book about how Semler threw out everything most “experts” know about running business and instead empowered his workers to do awesome things.

Thanks to everyone who attended my talks. I hope you got something useful out of them!

Using TortoiseSVN From the Command Line

I use batch files to automate much of my build process steps. I’ll grab the latest from our source repository with one batch file, build trunk with another, and finally set up my baseline data with a third. This lets me tie these command files to SlickRun hotkeys so I can launch everything with a keystroke or two.

If you use TortoiseSVN it may not be apparent, but you can use it via the command line by invoking the TortoiseProc.exe file and passing in a couple command args. For example, to do an SVN update and get latest you’d call:

"d:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:"update" /path:”<working_copy>”

Note that you must have the quotes around the specific command you want to run, and you’ll also need quotes around the path you’re wanting to update. You can also update the current directory you’re in by using /path:. – note that’s the period denoting the current working directory.

You can read more about the available commands in TortoseSVN’s documentation.

Help Me Help Hanselman Help Diabetics

This bracelet hangs on my wrist and is a pretty good metaphor for me these days. It’s scratched, it’s bent, it’s beat up, and it’s hanging in despite some rough wear over the last year. The first three words engraved on the back sum up the central aspect of my life since June 11th, 2009: “James H. Holmes. Diabetic.” (OK, so that’s three words plus an initial. Go with it, OK?)

I’ve gotten a lot of attention at the Wright Patterson clinic since last summer when, at 45 years of age I was diagnosed with Type 1 diabetes. Most Type 1 diabetics come about in early childhood, a few in teens, and a very few in their 20s.  Turns out some bug got in my system and went to war with my pancreas. The bug won, and now the bracelet symbolizes a major part of who I’ll be the rest of my life.

Everything’s working out more or less fine, so please don’t flip out about me. Exercise coupled with discipline around my already very good eating habits are serving me well. Thank God this happened to me later in life when I’m better able to deal with it instead of some years prior when I would have just put a serious chip on my shoulder.

With all that laid out, go read Scott Hanselman’s blog post about his Diabetes Walk coming up later this year. Hansleman’s an amazingly open guy about his life experiences with diabetes, and with his huge reading audience his goal of raising $50,000 is absolutely reachable. His few words about kids with diabetes are better written than I’ll ever be able to write up.

Do me a favor: go donate a few bucks. Not for me, not necessarily for Hansleman, but for those diabetics, current and future, who are in great need of help fighting and surviving this disease.

Fixing “Invalid search path” for LIB environment variable in MSBuild

Problem: Trying to run msbuild.exe against a .sln file results in a failed build with an error message containing the error

error CS1668 : Warning as error : Invalid search path 'C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib'
 specified in 'LIB environment variable' -- 'The system cannot find the path specified. '

Examining the path C:\Program Files\Microsoft SDKs\Windows\v6.0A shows no \lib folder present.

Solution: Simply add an empty \lib folder. MSBuild doesn’t actually need anything in the SDKs folder for most builds; however, the vsvars32.bat file sets that directory as the LIB environment variable anyway.

This hacky fix has worked for me on a number of different systems and I’ve yet to run across any real issues. I’m blogging it here so I’ll remember next time without having to spend too much time searching…

Fixing “The Group Policy Client Service failed the logon”

We’ve had a rough few days with some virtualized servers on our testing infrastructure. Some SAN issues required some repair installs on a couple VMs, then we had a couple corrupted partitions on those VMs.

I’d fixed all those issues up, but ran in to problems trying to RDP directly in to the systems. I’d get errors “the Group Policy Client Service failed the logon” after entering my credentials.

Turns out the user profile on the server was corrupted. I didn’t have much in there, so I simply deleted it (System, Advanced Properties, User Profiles). This deleted the corrupted profile and I was able to get on the system successfully.

Book Review: 97 Things Every Programmer Should Know

97 Things Every Programmer Should Know, edited by Kevin Henney, pub by O’Reilly, ISBN 0596809484.

This is another great book in O’Reilly’s “97 Things Every <fill in the blank> Should Know” series, and it’s every bit as good as the others. The book follows the same highly successful format of creating a book full of two-page articles taken from submissions to a public wiki. Each article is concise, highly pertinent to our profession, and well-written.

The articles are grouped in broad categories such as Bugs and Fixes, Design Principles and Coding Techniques, Refactoring, and Tests/Testing/Testers. There’s a couple great sections on softer skills such as learning/continuing education and customer interaction. I was really impressed that the testing section was so long with such great content in it.

Nearly every article in the book was highly useful to me, but a couple highlights would have to include:

• Bob Martin’s The Boy Scout Rule on leaving code better than you found it
• Steve Smith’s Don’t Repeat Yourself on keeping duplication out of your design and code
• Jon Jagger’s Do Lots of Deliberate Practice on how to improve your skills
• Paul Homer’s Simplicity Comes from Reduction on the power of deleting code

This book’s nicely balanced between highly technical concepts (avoiding Singleton patterns, code metrics) and more general topics (education, scheduling). It’s a great addition to your bookshelf.

Kalamazoo X is This Weekend!

Last year I got to attend an amazing conference: The Kalamazoo X Conference. Mike Eaton put on an amazing conference with a terrific lineup and a fantastic format: 20 minute talks from great folks like Mike Wood, Brian Prince, Leon Gersing, and others. (I’m leaving off all the other great speakers because of time and space. Don’t take it personally if you were one.)

KalX’s content isn’t about in-depth technical geekery, it’s about communication, process, design, and figuring out how to improve and motivate yourself.

KalX is back this year, and it’s this weekend. You NEED to go to this conference. It’s like a combination of CodeMash and TED all mashed up in one day of glorious, awesometastic content.

Shake out your schedule. Get there. It’s the region’s second best conference after CodeMash, and I don’t say that lightly.

Warming up Sites Before Running Selenium Tests with NUnit’s SetUpFixture

I’ve been running in to a number of problems where my Selenium tests are timing out when they first run in our automated build environment. Our Selenium test build runs three times a day and sets up the environment from scratch using a distribution package created in another automated build process. [Note: This meets my goal of always testing what you release, not just what you can build.]

The issue with starting from scratch every time is that ASP.NET has to compile the site the first time a Selenium instance spins up. This takes long enough that several tests can fail due to timeouts. My local repave process (hacked together from several PowerShell scripts) hits the site before launching my tests; however, I needed some way to do this within my test process.

NUnit’s SetUpFixture attribute to the rescue!

This handy attribute lets you mark a class to run a one-time setup or teardown for a namespace or for an entire assembly. If you qualify the class with a namespace, then setup/teardown will run once for that namespace only. If you don’t qualify the class with a namespace it will run once for the entire assembly it resides in.

This is awesome.

Using this approach, I can fire up a WebClient instance and hit URLs which will force compilation of the target sites. Here’s how I do it:

using System;
using System.Net;
using NUnit.Framework;
using Telligent.Evolution.Tests.Selenium.Common;


[SetUpFixture]
public class AssemblySetupFixture
{
    [SetUp]
    public void WarmUpSiteAndControlPanelBeforeTesting()
    {
        try
        {
            var webClient = new WebClient();
            webClient.Proxy = null;
            var requestUrl = http://MyHost/SomeUrl;
            var result = webClient.DownloadString(requestUrl);
            requestUrl += "/ADeeperUrl/";
            result = webClient.DownloadString(requestUrl);
        }
        catch (Exception e)
        {
            Console.WriteLine(e);
        }
    }
}

Note there’s no namespace declared, so this snippet runs once for the assembly it runs in. Yes, the catch block is ugly, but this is my first pass at this and I’ll figure out something smarter to do with Exceptions later.

There are a number of ways I could have skinned this cat, but frankly I’d been wanting to try out this NUnit feature for some time and this gave me a nail to use that hammer on. (Because you can’t get enough bad metaphors in one sentence…)

Selenium Exception: Unable to Delete File (parent.lock)

Problem: When using FireFox for Selenium tests, Selenium RC is throwing exceptions with the error message “Selenium.SeleniumException: Failed to start new browser session: Unable to delete file” with a reference to a “parent.lock” file in your temp folder. Cleaning up FireFox profiles doesn’t help.

Solution: You may be using an older version of the selenium-server.jar. Go grab the latest download of Selenium RC. At least that’s what fixed it for us…

Getting an Assembly From the GAC

Windows Explorer lets you browse the Global Assembly Cache (GAC) and drop strongly-named assemblies in if you’ve the proper permissions. What you can’t do is pull things out of the GAC using Explorer. Explorer hides some abstractions of the GAC from you, preventing you from pulling assemblies out.

I had the need to validate that an assembly in the GAC was indeed the version I expected; however, once a file’s in the GAC you can’t just drag it out using Explorer. (I couldn’t rely on the Version number shown in Explorer – it’s a DLL related to some SharePoint work and the pain of dealing with versioned assemblies in SharePoint is a rant I’ll save you from. Today.)

You can get around this with a quick bit of command-line fu, though. Actually, it’s just copy, so it’s not even fu.

Using an admin account, open a command prompt and change to the %SYSTEMROOT%\assembly folder. There are a number of folders under here:

C:\Windows\assembly>dir /b
GAC
GAC_32
GAC_64
GAC_MSIL
NativeImages_v2.0.50727_32
NativeImages_v2.0.50727_64
temp
tmp

Use dir /s to find the assembly you’re looking for. (Line breaks inserted)

C:\Windows\assembly>dir TelligentEvolution.Wss.Global.dll /s /b
C:\Windows\assembly\GAC_MSIL\TelligentEvolution.Wss.Global
       \4.1.31029.3047__454c7a96e9526647\TelligentEvolution.Wss.Global.dll

Now you’ve got the full path to the assembly. Use copy to get it where you want it.

C:\Windows\assembly>copy GAC_MSIL\TelligentEvolution.Wss.Global
   \4.1.31029.3047__454c7a96e9526647\TelligentEvolution.Wss.Global.dll 
   d:\temp
        1 file(s) copied.

Poof. Now I can get at the file with Reflector for a bit of inspection.

Software Engineering 101 in Nashville on 2/27

Jon Kruger, Leon Gersing, and I are repeating our highly successful SWE 101 event (event wrap up blogged here) in Nashville, TN, on 2/27. Registration’s already open, so please join us if you’re in the area.

Oh, wait! You can actually attend via a Live Webcast if you’re not in the area! Register for that here.

The event’s schedule’s on the registration pages, but it will follow the same format as the one in Columbus: the morning focuses on laying out fundamentals, and the afternoon is all hands-on test driven development putting the morning’s content to practical use.

Come prepared to learn, interact, pair up, and cut some code with other geeks. It’s how we roll.

Case Studies on Benefits of TDD

I’m a believer in test driven development. For many reasons. I don’t do it enough myself, the people I’m around don’t do it enough, the people I talk to don’t do it enough. For many reasons.

One commonly cited reason is a lack of evidence about TDD’s benefits. I’ve always found that a bogus argument, because I think it’s fairly easy to look to specific metrics around code complexity and bugs in a before/after environment.

Without further ado, here are some links pointing to various studies on TDD. Note these links are to TDD. I didn’t even go down the route of “show me stuff that backs up the benefits of unit testing, not just TDD.”

Using Bing I Googled this search phrase: “test driven development studies” and got these great hits:

From Biblio, an entire page of studies.

In InfoQ, an article on a study from folks at Microsoft and IBM. The InfoQ article links to the Empirical Software Engineering Journal’s article which costs $34 to read. Evil, greedy, profit-grubbing Microsoft hosts the article here for free. A comment in the InfoQ article points out some great contrarian questions which you need to ask yourself about TDD.

There’s also a video on Channel 9 interviewing one of the study’s authors. (I haven’t watched it. Yet.)

An interesting paper summarizing several other studies in industrial, semi-industrial, and academic environments. Benefits in the latter two environments were not as apparent, particularly in the academic. I wonder if some the low benefit in the academic environment is due to a lack of real-world experience both in the students and their instructors.

Does Test Driven Development Really Improve Software Design Quality an awesome article published in IEEE Software back in March/April 2008. Read closely the sections on misconceptions and cons. Chase down some of the other referenced reading there, too.

Hopefully you’ll find these articles and links a good starting point for your own reading. Use them wisely when trying to make the case for selling TDD (or even just unit testing, period) to your teams, management, and customers. Keep in mind these critical points:

• Be honest. Unit testing and TDD aren’t silver bullets. Crap code driven by crap tests driven by crap requirements is still a pile of crap.
• Be honest. Your perceived productivity will drop. You’ll be knocking out less features on any given iteration/cycle/release.
• Be honest. You’ll suffer additional productivity losses as you learn how to do testing, preferably in TDD fashion.
• Be honest. There will be culture and skills issues with your team, your management, your customer, and you.
• Be honest. Testing and TDD is often more about long-term gains than short term. You’re trading feature velocity for overall quality and maintainability.
• Be positive. The gains you’ll realize from moving to TDD are significant: reliability, quality, maintainability.
• Be positive. The speed at which you’ll realize those gains will greatly improve as you move forward and get up over the learning curve.
• Be positive. There’s a growing mountain of solid study-based evidence around the benefits of unit testing, particularly TDD. I emphasized “evidence” because too often we geeks get so fired up about things that we are passionate about that we ignore arguments based on facts and evidence.
• Be positive. There are specific metrics you can use to show the gains: complexity metrics (NDepend, FTW!), code coverage, decreasing bug counts, fewer escaped-to-customer bugs, increased velocity around future maintenance and expansion.

Now go forth and do battle! “Sancho, my armor!”

Making DevExpress & ReSharper Play Nicely

I use both DevExpress’s IDETools and JetBrains ReSharper on my dev boxes. Why? Because I’m a tool whore. That and I like different pieces of both of them. DevExpress gives me awesome visualization, and R# gives me awesome other stuff.

Here’s my quick steps to making them play nicely together in VS 2008:

1. Install DevExpress tools first
2. Install ReSharper
3. Start VS, fill out license info as you’re prompted
4. Tell ReSharper to use R#/IntelliJ key mappings
5. Disable DevExpress options I don’t like
1. DevExpress | Options
2. Set Level to Expert (lower left corner of dialog)
3. Editor | Auto Complete | Intellassist | Setup | clear Enabled checkbox (I like R# completion better)
4. Editor | Auto Complete | Intellassist |Parens & Brackets | clear both options for Smart Parens and Smart Brackets (I’ve always had grief with these conflicting, so I shut ‘em off)
5. Editor | Clipboard | Smart Cut(Copy) | clear Enabled (Plain ol’ VS copy/cut/paste works for me)
6. IDE | Shortcuts | search for Ctrl-B (PasteReplaceWord) | clear Enabled (I use Ctrl-B in R# to go to definition)
7. IDE | Shortcuts | search for Ctrl-Alt-F (QuickFileNav modal) | clear Enabled (I use this shortcut in R# for formatting code. R# gives me Crtl-N and Ctrl-Shift-N for type/file nav)
6. Force ReSharper once more to use its shortcuts. ReSharper | Options | General | Visual Studio Integration | Restore ReSharper keyboard shortcuts | ReSharper 2.0 or IntelliJ IDEA | Apply

These are MY preferences, but it’s what works for me.

Flag Parameters are Evil! (Or at least unclear)

The more parameters you have in a method call, the more chances you have to screw things up. Moreover, method signatures with boolean parameters (flags) add in clarity problems, too – even if the input parameter is well-named.

Instead of exposing a non-private method with a flag, make that method private and instead expose two well-named, explicit methods which are simple facades over the newly private method.

Instead of

protected T CreateRestServiceInstance<T>(bool impersonateEnabled)

use

protected T CreateRestServiceInstanceAsServiceUser<T>()
{
   return CreateRestServiceInstance<T>(false);
}

protected T CreateRestServiceInstanceWithImpersonation<T>()
{
   return CreateRestServiceInstance<T>(true);
}

private T CreateRestServiceInstance<T>(bool impersonateEnabled) 
{
  //wonderful shiny stuff here
}

You’re making your class’s API explicit and clear, and you’re cutting the risk of someone goofing up and missing something important – like invoking a REST endpoint as a service account instead of impersonating the user.

Not that I’ve ever done this myself, mind you…