I’ve been a slow convert to the whole test-driven development movement. I’m ashamed, but it’s true. I’ve believed in TDD in principle, but when it came down to it, designing specifically for testability always made my code feel so bloated. I always ended up writing unit tests after the fact, and many times would end up writing loads of helper objects and dummy interface implementations to get things to work.

No longer.

We started looking at mock object frameworks for the latest project at work. After checking out Rhino Mocks (admittedly a decent framework), we stumbled upon TypeMock.

Holy crap, this thing is hot. In technical terms, you might call it the bomb-diggity.

There are several things that make TypeMock the framework to go with. The syntax of the “Natural Mocks” is nice and clean, making the majority of the mocking easy to use. It’ll mock static methods, constructors (and static constructors), and non-public methods - stuff Rhino [currently] won’t let you do.

“But,” you might say, “mocking frameworks are hard to work with because you can’t really see what’s going on ‘behind the scenes.’”

No longer! TypeMock has a trace utility where you can watch in real-time as the mock framework sets up and fulfills expectations. If you want to know what it’s doing, check the window. Want to know specifically what expectations are set up and which ones were left? It’s right there. No more fighting with stack traces and expectation exceptions. It really doesn’t get any easier than this.

A co-worker showed me some code he had written using Rhino. Frankly, I found it confusing and it wasn’t his code making it that way. I tried writing my own tests in it and had a heck of a time figuring it out. I picked up TypeMock this morning and minutes later was flying through it.

Ever tried to test an abstract class? You know how you have to create a dummy class that implements all the abstract stuff just so you can test the functionality? Not anymore - you can get a mock of the abstract class with no “placeholder” or “dummy” classes. Ever tried to test a factory that returns values based on configuration files in the filesystem? You know how you end up having to dump fake config to just the right spots in the filesystem in order to test that factory? And you know how much more trouble it is to test classes that make use of that factory? Forget that. No more having to fight with all that. It’s a piece of freakin’ cake.

Let’s use that factory example. Say I have a factory called CoolFactory that has a method CoolFactory.GetCoolObject(). That method looks up a value in configuration and returns an object of type CoolObject. Now say you have a class called WorkingClass (pun?) that uses the CoolFactory to do some work in the WorkingClass.DoWork() method.

You used to have two options: either over-architect CoolFactory and have a load of various pluggable providers that the factory could use and clutter the API with so you can sub in configuration at test time; or set up configuration, dummy objects, etc., all to support a single test.

With TypeMock, you can mock that static CoolFactory.GetCoolObject() method and skip all that. Here’s what an NUnit test might look like:

[Test]
public void MyTest(){
  // Set up the object you want the factory to return here
  CoolObject factoryGenerated = new CoolObject();

  // Record the actions you want to play back
  // and tell the factory to return your object.
  using (RecordExpectations recorder = new RecordExpectations()){
    CoolFactory.GetCoolObject();
    recorder.Return(factoryGenerated);
  }

  // Call the method that uses the factory
  WorkingClass testObj = new WorkingClass();
  testObj.DoWork();

  // Make your test assertions here...

  // Verify the DoWork method called the factory
  MockManager.Verify();
}

That’s it - when the DoWork method calls the factory, it’ll return the object you set up. No need to dump config to the filesystem, over-architect the factory, or dummy up a lot of extra “helper” classes.

I haven’t been this stoked about a technology for quite some time.

Now, I’m using the Enterprise edition (they offer a “community edition” that doesn’t have the “Natural Mocks” in it - don’t bother with that, you want the Natural Mocks). I’m not sure if I’d have been so excited if I was stuck at the “community edition” level. But I’m not, so I’ll play ignorant and revel in what I’ve got.

No more designing for testability! No more huge efforts to create dummy objects to get various components working and tested!

You know what? With a framework like TypeMock, I can 100% buy into test-driven development. I can keep API as a deliverable and still get full test coverage - I get my cake and I eat it, too.

Check out TypeMock. You’ll be glad you did.

Lately at work we’ve been working towards test driven development and not just “having a lot of tests.” For pretty much anyone who has written unit tests for anything with any complexity, you know that’s a lot harder than it sounds. You need to be able to test certain components in an isolated fashion and the bits that you need to integrate with may not actually be written yet.

To get around this, you generally end up writing a lot of test and helper classes to stub in the functionality your component interacts with, but that’s a heck of a lot of work. In some cases, you might have to drop live configuration files into the system to get things to work correctly, you might need to craft some dynamic logic into your test classes… it’s a big pain.

Some folks choose to architect their components to be easier to test. This usually implies there are more publicly exposed methods than you might normally have so that certain internal properties can be checked on, substituted in, or otherwise dealt with in a test environment. It also means there are a lot more moving parts - interfaces for “plugging in” components that wouldn’t normally be there except for the need to swap in at test time. We’ll call that “designing for testability.”

Unfortunately, much of what I work on has the API as a deliverable. Which is to say, I can’t just have a load of exposed public methods floating out there solely to support my tests. I can’t “over-architect” the usage of the components because part of the goal is to make the components simple to use. Instead of designing for testability, we have to test what’s designed.

The problem, then, is how to “plug in” or stub out things in testing to isolate the component being tested? Enter mock object frameworks.

Mock object frameworks allow you to do that sort of thing on the fly. You can say “give me a mock data provider and whenever anyone queries it for data, have it return this data set here.” It’s a really nice, simple way of doing things that doesn’t require you to bloat your design just so you can test it.

Okay, so that’s your quick “mock objects” intro. The question I’m leading to is: mock objects are very powerful. You can do a lot of stuff with them. So much, that if you aren’t really paying attention, you could very well mock your way into invalid tests. The question on the table, then, is “are mock objects too powerful?”

This is actually an ongoing debate at work as we investigate different mock object frameworks. If we end up with a site license for a fairly powerful mock object framework, what’s to stop an untrained developer from misusing it and giving us a false sense of quality by writing invalid tests?

My view: it’s a tool, like a screwdriver or a hammer. Or matches. If you don’t know what you’re doing with the matches, you’re going to get burned. If you know what you’re doing, matches can be very helpful. It all comes down to education. People just need to be smart enough to know when they’re not smart enough to start using the tool and get educated before picking it up and heading down that path. I don’t think “people might misuse it” is a convincing enough argument to not use the tool. I might also consider that if it’s worrisome to a particular team or project, the folks overseeing that team or project need to pay attention and ensure the right tools are being used by the right people for the job.

Besides, there are so many other ways the uninitiated can mess up production code, somehow I think “using a mock object framework improperly in testing” doesn’t qualify on the top 10 threat list.

After thinking about it for a while and talking about it for, like, a year or more, I finally stepped up and bought myself a PSP (PlayStation Portable).

I realize I’m a little late to the show on this one, but it’s pretty bad-ass. The screen is nice and crisp, no dead/stuck pixels (that I’ve found so far), and I’ve got a couple of games for it that are pretty neat.

I actually ended up with it since I’m going to be taking a couple of trips soon (Vegas this weekend, Aruba for the honeymoon) and want to watch some movies and play games on the flight. I figured, for the price, as a portable game and media platform, it can’t be beat. Plus the package I got was pretty good for all the extra stuff you get.

Now I just need to get a protective case and I’m set to go.

Stu, Jason, Jason’s brother Adam, and I are all going to Vegas next weekend for my bachelor party. Come 9:30p on Saturday the 30th, though, you know where I’ll be?

Front and center for the Cirque du Soleil show, KA!

Actually, literally front and center. Stu and I, middle of the first row. Of course, tickets are $150 a piece, so I can’t say it didn’t cost me, but I’ve yet to be disappointed by a Cirque show.

Oh, hell yeah. I’m altogether too stoked. Jenn is going to be soooo jealous.

I’ve been considering getting a PSP for a while now but just haven’t been pushed over the edge. My gadget interest has been generally low for a while with no cool tech really calling out to me lately, so the PSP has surfaced again as something I might be interested in.

I was at the store this morning picking up a copy of the Rush album The Spirit of Radio: Greatest Hits 1974 - 1987 (Neil Peart being arguably the best drummer ever) and the guy at the store mentioned they were coming out with a new PSP value pack of some sort that includes more stuff.

A little research brings us to the PSP Entertainment Pack, which is like the existing “Value Pack” but with a 1GB memory stick, a movie, and a game. A little better deal for the money, though, granted, the system’s not brand-spanking-new to the market, either.

It’s something to think about. I hate to be on the tail end of technology, but it’s becoming a better deal so it might be worth a shot.