With November behind us, there’s now a month of TextMate productivity tips scattered across the twitterverse. In case you missed any of them, here’s a recap:

• November 1 - Use Control+Option+Command+V to view your clipboard history. Then hit Enter to paste the selected item into the current document.
• November 2 - Use Control+Shift+C to access the Math bundle from any file. Instantly perform calculations, add/subtract selected numbers, and more.
• November 3 - With your cursor on any Ruby string, use Control+Shift+' to toggle between single quotes, double quotes, and %Q{}. Also works with Groovy, JavaScript, Perl, SQL, Bash, etc.
• November 4 - In HTML (or HTML-friendly) files, select several lines and use Control+Command+Shift+W to wrap each line in a pair of HTML tags.
• November 5 - Control+Escape brings up the automation menu. Use it for quick access to the current bundle and to navigate through other bundles.
• November 6 - With your cursor on any Ruby symbol, use Control+: to change it to a string. Use Control+: again to toggle back to a symbol.
• November 7 - Folding is (almost always) evil and is triggered by accident more often than not. Turn it off in View -> Gutter -> Foldings.
• November 8 - For the rare occasion when you want folding, use F1 to fold the current block. Use Command+Option+n (where n is a digit) to toggle foldings at the nth level.
• November 9 - With your cursor on a misspelled word, use Option+F2 to bring up suggested spelling corrections. Hit Enter to choose a correction.
• November 10 - With your cursor on any ActiveRecord model, use Control+Command+Shift+S to instantly view the schema for that model.
• November 11 - When working w/ CSS, use Command+Shift+C to bring up the OS X color palette. Choose a color to insert the corresponding hex code.
• November 12 - Selection-fu => Use Control+W to select the current word. Use Command+Shift+L to select the current line.
• November 13 - Use Control+H to pull up the documentation for the selected word. Works for CSS attributes, Ruby methods, HTML tags, Javadoc, etc.
• November 14 - Anywhere that ERb is supported, use Control+> to produce a <%= %> sequence. Hit it again to cycle through the various flavors.
• November 15 - Need fast access to placeholder text? Type “lorem” and hit Tab.
• November 16 - Sometimes TextMate is too smart for its own good. Use Control+Command+V to paste without reindent. Especially useful for YAML.
• November 17 - Fun with case conversions - Control+U => TO UPPERCASE. Control+Shift+U => to lowercase. Control+Option+U => Convert to Titlecase.
• November 18 - Use Control+Tab to toggle focus between the editor window and the folder/file tree in the project drawer.
• November 19 - Don’t lose time waiting for “Find in Project” to slog through a large project. Search fast w/ Ack in Project.
• November 20 - Use Control+Option+Command+P to preview the current file as rendered HTML. Good for HTML (duh), Markdown, and Textile.
• November 21 - Command+Option+[ => Format current selection (or current line if nothing is selected) according to rules for the current grammar.
• November 22 - Use Option+PageUp and Option+PageDown to page up/down while keeping your cursor in the middle of the screen. (On a laptop, PageUp is Function+Up. So, for this tip, you’d use Function+Option+Up and Function+Option+Down.)
• November 23 - Use Command+Option+W to toggle soft line wrapping.
• November 24 - Hit Escape to auto-complete the current word using similar words in the current file (in order of their proximity to the cursor).
• November 25 - Enable “Edit in TextMate” to use TextMate from any Cocoa app - email in Mail.app, blog comments & wikis in Safari, etc.
• November 26 - Use Option+Command+R to feed the current file (or selection) to any shell command and capture the output in any number of ways.
• November 27 - Use Control+Option+Shift+H to change the language of the current file to HTML. Use ‘X’ for XML or XSL. ‘R’ for Ruby, Rails, etc.
• November 28 - Command+Shift+T => Go to symbol. This grammar-sensitive fuzzy finder locates classes & methods in Ruby, IDs in HTML, etc.
• November 29 - Hold down the Option key while selecting an area of text to make a columnar selection. More info here http://bit.ly/tmcol.
• November 30 - Forgot how to access a certain feature of TextMate. Quickly find any and all of the TMOBGOTD tips (and more) with Command+Shift+?

And if you’re still following along, you’re hardcore enough that you’ll want to make sure that the bonus inaugural entry is firmly tucked into your TextMate black belt as well:

• October 31 - Control+Command+T => Fuzzy find for bundle items.

Got a favorite TextMate tip of your own to share? Tag it with the worst acronym ever (TMOBGOTD - TextMate Oldie But Goodie Of The Day) for all the TextMate-lovin’ world to see.

I had the pleasure of meeting a local Grails enthusiast last night who was new to the Triangle, but I was disappointed to see the same old argument spoil the show. The Rails vs. Grails debate is tired, and it’s curiously - perhaps even embarrassingly - unidirectional. I hereby call on the great philosophers to weigh in:

Philosopher, The First

Philosopher, The Second

Now, go in peace.

–

Update 2008-11-19 - Robert has deleted his comment (originally linked to above and referenced by Robert below) from his blog. His original blog post remains intact, sans incendiary comment.

I’ve had the joy of calling TextMate my editor of choice for almost three years now, and as the The Pragmatic Programmer wisely recommends, my editor has definitely grown to become “an extension of [my] hand.” Often when giving a presentation or pair programming, someone will stop me to ask, “Wait a minute. How’d you do that?” “That” is inevitably in reference to some bit of hyper-productive TextMate keyboard wizardry that eliminated several steps the person was otherwise expecting to see. Of course, a few years ago you were more likely to hear me asking that question. (And I still love it when I get to ask that question nowadays.)

For the month of November, I’ll share one of these “How’d you do that?” tips each day. They’re by no means revolutionary; they’re much more in the oldie but goodie camp. Hence the name: TextMate Oldie But Goodie Of The Day (TMOBGOTD). Each one can shave time - sometimes several seconds - off of common tasks. And if they’re common tasks in your workflow, then that time surely adds up.

You can follow along at twitter.com/jasonrudolph, where the first four tips are already in place.

1. November 1 - Use Control+Option+Command+V to view your clipboard history. Then hit Enter to paste the selected item into the current document.
2. November 2 - Use Control+Shift+C to access the Math bundle from any file. Instantly perform calculations, add/subtract selected numbers, and more.
3. November 3 - With your cursor on any Ruby string, use Control+Shift+' to toggle between single quotes, double quotes, and %Q{}. Also works with Groovy, JavaScript, Perl, SQL, Bash, etc.
4. November 4 - In HTML (or HTML-friendly) files, select several lines and use Control+Command+Shift+W to wrap each line in a pair of HTML tags.

Whether you’re seeing these techniques for the first time or rediscovering a command that you’d forgotten about, take a moment to try it out. Perform each technique three times, and you’ll be well on your way to committing it to memory. In just 60 seconds a day, you too can train to become a TextMate black belt. Or double your money back. Guaranteed.

–

Update 2008-12-02 - Check out the full list of tips in the wrap-up post.

While working on the Testing Anti-Patterns series over the past few months, I’ve had the pleasure of reading some great writing on testing, test-driven development, code coverage analysis, and the bigger picture of software quality in general. What follows is a collection of some of my favorite findings: quotes and resources spanning the last ten years and then some.

How Not to Test

Let’s start off with something light. James Carr’s TDD Anti-Pattern Catalogue is a good, fun read that’s downright hilarious at times (but only because we remember writing seeing these tests once or twice). And not only are the anti-patterns that James proposes worth reading, you owe it to yourself to check out the extensive discussion in the comments as well. There you’ll find folks chiming in with many additional gems, including:

• The Blue Moon - Matt Simner’s aptly-named anti-pattern is one we’ve all hit at least once: “A test that’s specifically dependent on the current date, and fails as a result of things like public holidays, leap years, weekends, 5-week months, etc.” Ouch.
• Honest Guv - Graham Lenton’s contribution to the list brings back some memories I’d rather forget: “Where the expected outcome is so entropic that the developer simply asserts true with a comment ‘this works, honestly.’” Um. Sure it does.

We’re Still Figuring This Stuff Out

Some tests are just so incredibly rotten that it’s easy to definitively declare a better approach, but it’s not always that black and white. Just as we have to make trade-offs when designing and developing production code, so too do we have to weigh the advantages and disadvantages of the available approaches for testing that code.

In his post on Developer Testing and the Importance of Context, Jay Fields reflects on the catalog of testing patterns he’s documented over the past few years, and he reminds us that “context is still king:”

You’ll find that some of [the] approaches are in direct conflict. This isn’t because one pattern is superior to another in isolation, it’s because one pattern is superior to another in context.

Software development certainly isn’t the only engineering discipline that requires its practitioners to manage trade-offs, so how do we compare with other industries? The often controversial (but always entertaining) Neal Ford argues that “testing is the engineering rigor of software development,” but that we’ve still got a long way to go if software development will ever truly be an engineering discipline:

It may just be that software will always resist traditional engineering kinds of analysis. We’ll know in a few thousand years, when we’ve been building software as long as we’ve been building bridges. We’re currently at the level in software where bridge builders were when they built a bridge, ran a heavy cart across it, and it collapsed. “Well, that wasn’t a very good bridge. Let’s try again.”

Pragmatic Use of Code Coverage Analysis

We’ve talked quite a bit about code coverage in our discussion of testing anti-patterns. Brian Marick’s 1997 paper titled How to Misuse Code Coverage is a must-read, full of pragmatic advice from a veteran tester:

I’ve written four coverage tools … I still find myself looking at a coverage condition, saying “I know how to satisfy that,” and getting an almost physical urge to write a quick-and-dirty test that would make the coverage tool happy. It’s only the certain knowledge that customers don’t care if the coverage tool is happy that restrains me.

The most common coverage mistake is giving into that urge. I warn against it by saying that coverage tools don’t give commands (”make that evaluate true”), they give clues (”you made some mistakes somewhere around there”). If you treat their clues as commands, you’ll end up in the fable of the Sorcerer’s Apprentice: causing a disaster because your tools do something very precisely, very enthusiastically, and with inhuman efficiency - but that something is only what you thought you wanted.

Designing your initial test suite to achieve 100% coverage is an even worse idea. It’s a sure way to create a test suite weak at finding those all-important faults of omission. Further, the coverage tool can no longer tell you where your test suite is weak - because it’s uniformly weak in precisely the way that coverage can’t directly detect. Don’t use code coverage in test design. The return on your testing dollar (in terms of bugs found) is too low.

Now that we know how to misuse code coverage, the Google Testing Blog weighs in on the proper application of coverage analysis:

1. Make your tests as comprehensive as you can, without coverage in mind. This means writing as many test cases as are necessary, not just the minimum set of test cases to achieve maximum coverage.

2. Check coverage results from your tests. Find code that’s missed in your testing. Also look for unexpected coverage patterns, which usually indicate bugs.

3. Add additional test cases to address the missed cases you found in step 2.

4. Repeat step 2-3 until it’s no longer cost effective. If it is too difficult to test some of the corner cases, you may want to consider refactoring to improve testability.

In Code Complete, Steve McConnell offers sage advice for knowing when you can reasonably move to Step 2. (Hint: Just testing the happy path ain’t gonna get you there.):

Immature testing organizations tend to have about five clean tests for every dirty test. Mature testing organizations tend to have five dirty tests for every clean test. This ratio is not reversed by reducing the clean tests; it’s done by creating 25 times as many dirty tests.

And we should always keep the value of code coverage (or any isolated metric for that matter) in perspective, as Andy Glover reminds us in his post on unambiguously analyzing metrics:

Metrics are more copasetic when combined with other metrics and trended – for instance, complexity alone is somewhat interesting, but pairing complexity with code coverage paints a much more detailed metric that bears understanding. High complexity with low coverage is clearly more risky than the same complexity with high code coverage …

Beyond Developer Testing

Not only should we avoid relying on a single metric, we should also be wary of relying too much on a single form (or a single “layer”) of testing. As Luke Francl argues in his call for more diverse testing, even the most exhaustive set of unit tests is limited in the scope of defects it can find [1]:

Don’t put all your eggs in one basket. The most interesting thing about these defect detection techniques is that they tend to find different errors. Unit testing finds certain errors; manual testing others; usability testing and code reviews still others.

In his post on The Ultimate Unit Test Failure, Jeff Atwood comes out swingin’ and begs development teams to invest in interaction design with the same enthusiasm (or perhaps more) that we give to developer testing:

Perfectly executed code coverage doesn’t mean users will use your program. Or that it’s even worth using in the first place.

No Silver Bullet

If there’s any one theme that we can observe across this collection of ideas, it’s the recognition that no recipe, or tool, or one-size-fits-all process offers the One True Way (TM) to develop quality software. As Michael Feathers points out, quality doesn’t come from a “mechanistic” approach to testing:

Quality is a function of thought and reflection - precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.

It’s only that critical thought that will tell us when it would be more cost-effective to use one flavor of testing over another. It’s only that critical thought that will uncover implied requirements in a user story or prompt us to ask about hidden assumptions that might be lingering in a given use case. It’s only that critical thought that will recognize when the pattern that’s worked for us 95% of the time simply isn’t appropriate for the particular scenario we’ve just come across. To forgo that critical thought in search of a silver bullet, that’s the ultimate testing anti-pattern.

Notes

[1] Luke notes that the specific overlaps in the diagram are admittedly arbitrary. The specific areas of overlap are insignificant for our purposes here. Noteworthy is that while there is some overlap between these forms of testing, each one tends to identify at least some defects that are less likely to be identified by other forms of testing. (Diagram used with permission.)

---

This series is taken from the How To Fail With 100% Test Coverage talk. Check the schedule for a talk near you.

–

Thanks to Stuart Halloway, Rob Sanheim, and Greg Vaughn for reading drafts of this post.

The Testing Anti-Patterns series began as a conference presentation titled How to Fail With 100% Test Coverage, and I recently had the pleasure of presenting that talk at the Raleigh-Area Ruby Brigade (raleigh.rb). Matthew Bass was kind enough to record the audio from the event, and I’ve taken a stab at syncing that audio with the slides for a full-on multimedia extravaganza.^§

Download Quicktime video via Vimeo (registration required)

Download MP3 via iTunes

Download MP3 directly

Download slides

Wanna see this talk live? Check the schedule for an event near you.

–

^§ Keynote’s Quicktime recording/exporting has a seemingly diabolical sense of humor. For comedic effect (or perhaps to make sure you’re paying attention), it likes to randomly shuffle the slides every once in a while. So in the video, you’ll notice that unfortunately the slides and the audio don’t always line up just right. If you find it too erratic, then it may be easier to listen to the audio and advance the slides manually. And if you see Tyler Durden make a cameo, well, it was probably just Keynote having a laugh.