It’s not as though unit testing is completely new to me, but even years after I wrote my first tests, I still consider myself a naive amateur in many regards. I’ve been ramping up my use of tests lately thanks in large part to a technique I read about in Michael Feathers’s book Working Effectively With Legacy Code.

Essentially, the idea is that before you do any major refactoring in your existing code base, you should attempt to locate a “bottleneck” to how that code is reached, and test the interface at that bottleneck. So, if all the code paths to Class A and Class B are through Class C, I can effectively just cover Class C with unit tests and be relatively certain that the functionality of Classes A and B are covered to the extent that I care about them.

Refactoring then becomes a lot less stressful, because you’re more likely to catch stupid mistakes and changes in functionality you might cause in the process. I realize that no set of tests is a guarantee against introducing new bugs, but in the process of covering classes with test coverage, you also end up learning quite a bit about what the classes actually do. This is no small victory when working with code that you either didn’t write, or that you haven’t reviewed in a number of years.

As I’ve become more and more dedicated to testing in my Mac and iPhone projects, the size of my test suites has grown. I’m subscribing to guidelines for good test writing: that they should be fast and as isolated as possible. But they still take a non-trivial amount of time to run. It’s gotten to the point where the tests for my “web publishing frameworks” take at least a minute to run on my MacBook. This is pretty fast in the big scheme of things, but a long time to wait when I’m engaged in a rapid edit, build, and test iteration.

I figured there must be some way to limit the test cases that get run to just the specific one I’m working on at the moment. And it turns out there is. Thanks to the “Other Test Flags” build setting in Xcode, I can temporarily change the behavior so that it runs only a subset of all the tests contained in my test bundle. For example, right now I’m working on tests that cover the functionality of my RSRESTCall class:

The -SenTest option is passed on to the test rig, in my case the default “otest” command that comes with Xcode. This lets the test rig know that instead of the default behavior of finding and running every test in the bundle, it should just run the tests in the “RSRestCallTests” SenTestCase subclass.

Something I didn’t mention yet but which is also aiding me greatly in the measuring my test coverage is the “gcov” library that also comes bundled with Apple’s developer tools. I’m using this to create a “Code Coverage” build of my code, that makes it possible to see exactly which lines of code did or did not get run during a particular set of tests. This, in conjunction with a cool application from Google’s Mac developers, makes it pretty easy for me to seek out uncovered areas of code, think about how to cover them with tests, and iterate.

My friend Gus Mueller of Flying Meat is having a busy week. On Tuesday it was revealed that his awesome image editing application, Acorn, is part of the MacHeist 3 Bundle. I have been openly critical of these rock-bottom-pricing bundles in the past, and I remain uncertain as to their long-term benefits for the Mac software ecosystem. But in the short-term, consumers obviously have the option of picking up some amazing software for an unbeatable price. And if folks like Gus end up benefiting then I wish them the best.

In the wake of his high profile MacHeist debut, Gus announced something new today which is decidedly less consumer-oriented (though if it takes off, it could certainly have wide-reaching consequences). JSTalk is Gus’s JavaScript-based answer to what he sees as outdated and clunky about AppleScript, Apple’s preferred scripting language on the Mac.

For starters, Gus’s JSTalk provides syntactic sugar on top of standard JavaScript in order to give it some comfortable Objective-C style conveniences. Then, he provides a teeny bit of source code that any application can embed in order to respond to incoming JavaScript commands. This results in a scenario where an Objective-C based application can easily expose its internals to other applications, so that a script written in JSTalk can control it from another application.

I’m excited about the idea of JavaScript taking a more prominent role in the scripting infrastructure of Mac OS X. In fact, about 9 months ago I wrote some challenging words about my opinion on the matter. Responding to Apple’s impressive enhancements to JavaScript in the context of WebKit:

I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.

Since then, Apple has given no indication of pursuing a system-wide infrastructure for JavaScript scripting. So in comes Gus Mueller with JSTalk, and solves the problem. Right? Well, sort of. Gus’s idea is very cool and clever given the constraints he’s working with. Namely, he can’t easily control how every application works, or how it interacts with the system and every other application. His solution is cool, and may even be worth adding support for to your application, but it’s not as cool as a system-wide, Apple-endorsed solution would be.

Michael Tsai makes some smart observations about JSTalk, also agreeing that it’s cool, but taking exception to Gus’s claim that getting away from the rigid structure of AppleScript’s XML-based scripting dictionaries is a good thing:

I think defining the object model, e.g. using XML, is a feature. Otherwise there’s no separation between the scripting interface and the application’s unstable internal interfaces.

Taking a closer look at Michael’s post, I think I could have avoided this somewhat long-winded post by starting simply with, “Yeah, what Michael said.”

I’m happy to announce that MarsEdit 2.3 is now officially released.

• Now supports Tumblr blogs
• Media manager now opens much faster with lots of photos
• Revision of the Technorati Tags editor
• Improved weblog Favicon detection

It feels great to finally have an official release out there that supports Tumblr. I would like to thank Marco Arment for his patience in working with me to improve the Tumblr API, so that it will work better with MarsEdit. There are still areas where we can improve the integration on both sides of equation, but I think this release represents a great start.

If you’ve got a blog and you haven’t tried MarsEdit before, give it a spin! Just put your blog’s home page URL in when MarsEdit asks for it, and you’ll be off and editing.

Scotty of the Mac Developer Network recently invited me to be a guest on his wonderful interview podcast, Developer Lives. It was a lot of fun and I was surprised by some of the memories I dug up in the process. If you’re interested in learning a bit more about my background and how I came to be a Mac developer who runs his own business, check it out!

While we’re talking of the Mac Developer Network, I would like to remind readers of Scotty’s upcoming NSConference, taking place next month in Hatfield, UK. The lineup of speakers looks awesome, and I’m sure it will be a lot of fun for all who can make it.