Apple has just announced Mountain Lion, the next version of OS X, due out in the summer. Although it’s more of an incremental upgrade than Lion was¹, one of the most interesting features is Gatekeeper. Gatekeeper, in brief, prevents unsigned code from running on OS X. Although it can be disabled, it’s on by default, and many feel this is the beginning of the end for users having full control of their computers. I feel the opposite: it’s not a slippery slope, and it’s actually a great feature.

In the last two posts about “clean tests”, we talked about the structure of a test, how to eliminate duplication, and how to make intent clear when using mocks. We left off with a question of magic values: Why do we seem to use them in our tests, when we know they are wrong in production code? Let’s explore that and see how to eliminate their use in our tests without making the tests hard to understand.

Hopefully you’ve read Steve Yegge’s excellent kingdom of nouns essay, in which he bemoans a pattern that exists in a lot of Java-base systems. The tell-tale sign is a class named ThingDoer with a single method doThing(). Systems like this don’t arise simply because Java is the way it is, but when you follow SOLID principles (particularly the single responsibility and dependency inversion principles), your code ends up with lots of small classes that do one thing only.

In Java, you are basically stuck with this, but in Ruby (or any OO language that supports closures/blocks/functions), we can fight this by using Procs instead of classes.

In a previous post, I talked about the overall structure of a test and how that was important to understand the test itself. A brief review:

• Given - Establish the conditions under which the test will run
• When - Run the code under test
• Then - assert that the code did what you expect

This structure becomes problematic when using either mock objects or block-based asserts.

Code comments often get a bad rap, especially in the Ruby community, with phrases like “code should be self-documenting” floating around, legitimizing the production of code with no documentation at all. In fact, code comments are one of the many useful tools developers have to make their intent clear, and writing them off as a “code smell” is naive and dangerous.

Some collegues and I were dicussing dupication in tests, specifically how much repitition of code across tests is acceptible. On the one hand, you want each test to stand on its own and indicate what it’s testing. On the other hand, just because we’re in a test doesn’t mean that all the rules about duplication of code don’t apply; tests need to be maintained to, and if you make a large change, you don’t want to have to change it in several places.

How much duplication is too much or, what does duplication in tests mean, and how does it affect the understandability and maintainability of our tests?

At the start of 2011, I blogged about a “professional goals” file I found on my computer, and compared it to what happened. I kindof enjoyed the exercise, so here’s a repeat.

I just finished reading the short and to-the-point Working with Unix Processes, by Jess Storimer. Although I cut my teeth on C and UNIX programming, it’s been a while, and I figured I’d check the book out to see what insights it might have, especially given that it’s written from a Ruby perspective.

In short, I’d recommend this book to someone interested in command-line Ruby (and who might have my book), but who has very little UNIX programming experience. This book is a crash-course in the basics of UNIX Process management.

That being said, if you are (or have been) familiar with things like fork and exec, you’ll find this book a bit too light, especially given the price (update 1/2/2012 see inside).