Jason Rudolph

Live JavaScript TDD Action Coming to raleigh.rb

2009-07-15T00:00:00-04:00

Next week at raleigh.rb, Larry Karnowski and I are pairing up for a round of live test-driven JavaScript development with Blue Ridge. Come see how easy and natural it can be to give your JavaScript code the testing love it deserves.

The meetup is at 7 PM on Tuesday, July 21. Hope to see you there!

Watch the preview on Vimeo. (Courtesy of Matthew Bass.)

Git Up! 10 Reasons to Upgrade Your Old Git Installation

2009-05-27T00:00:00-04:00

Git has seen a huge influx of newcomers over the past year. Many folks installed Git as they read through their first tutorial, got it working, and are still using that same trusty installation today. But rest assured, Git has not been standing still.

If you installed Git a year ago (perhaps when Rails made the move in April of last year), you would've grabbed v1.5.5. The Git team has cranked out five feature releases since then, full of usability improvements, a few new tricks, and, of course, numerous bug fixes. So it's time for some spring cleaning of your dusty old Git installation.

If you're not yet sportin' the 1.6.3 hotness, here are ten reasons to Git up!

And this is by no means an exhaustive list. An upgrade from v1.5.5 to v1.6.3 includes well over 100 improvements. While no one of these improvements is revolutionary, they each make this awesome VCS just a tad nicer. And collectively, they make it well worth the upgrade.

So what are you waiting for? Invest five minutes right now to upgrade. C'mon. You're sittin' around reading blogs. What else have you got to do? Git up!

Notes

If you're on OS X, I recommend using MacPorts for quick and easy upgrades. Let Rob Sanheim show you the way.

Image courtesy of Midnight Digital (flickr.com/midnight-digital). [Creative Commons License]

RailsConf 2009: JavaScript Testing in Rails Projects. No, Seriously!

2009-03-24T00:00:00-04:00

Going to RailsConf in Las Vegas this year? Larry Karnowski and I are presenting a session on giving your JavaScript code the testing love it deserves.

Our talk is on Tuesday, May 5 at 1:50 PM in Ballroom B.

JavaScript Testing in Rails: Fast, Headless, In-Browser. Pick Any Three.

You wouldn’t consider developing a Rails application without having a solid test suite for your Ruby code, but you’ve somehow convinced yourself to cross your fingers and look the other way when it comes to JavaScript. It doesn’t have to be that way. In this session, you’ll learn how to apply test-driven and behavior-driven development to your unobtrusive JavaScript code in a Rails-friendly manner.

Hope to see you there!

Developer Day: Evolving Your Git Workflow, and Much More

2009-03-12T00:00:00-04:00

Next Saturday, March 21, Viget Labs and Relevance, Inc. are presenting Developer Day, a one-day conference representing a veritable cornucopia of high-tech awesomeness.

Here's the rundown:

Staying current with the ever-evolving technological possibilities can be challenging, but you love trying. Why? Because you’re a fantastic web developer who loves building things, (and, frankly, that's just how you roll).

Which is why this conference is perfect for you.

Hear eight presentations given by active practitioners on topics ranging from JavaScript and Scala to Rails performance and security. Each is tailored to give you insight into various topics that may positively influence how you work, regardless of your specialization.

So, come meet cool people, eat some lunch (from local Durham restaurants), and give yourself the day to learn and participate in several great discussions — all for the low, low price of $50.

I'll be speaking about taking your Git-fu to the next level.

Evolving Your Git Workflow

Git has attracted many developers away from various centralized source control tools, but it’s easy to find yourself using Git like a slightly-better variant of your old VCS. “You don’t even have to be online to commit. Cool!” That’s a nice touch, but Git has way more to offer, and by picking up a few intermediate and advanced Git techniques, you can save a ton of time (and sanity) for yourself and your team.

Check out the site for registration and full details. Hope to see you there!

Git Tip: How to "Merge" Specific Files from Another Branch

2009-02-25T00:00:00-05:00

Problem Statement

Part of your team is hard at work developing a new feature in another branch. They've been working on the branch for several days now, and they've been committing changes every hour or so. Something comes up, and you need to add some of the code from that branch back into your mainline development branch. (For this example, we'll assume mainline development occurs in the master branch.) You're not ready to merge the entire feature branch into master just yet. The code you need to grab is isolated to a handful of files, and those files don't yet exist in the master branch.

Buckets o' Fail

This seems like it should be a simple enough task, so we start rummaging through our Git toolbox looking for just the right instrument.

Idea, the First. Isn't this exactly what git cherry-pick is made for? Not so fast. The team has made numerous commits to the files in question. git cherry-pick wants to merge a commit - not a file - from one branch into another branch. We don't want to have to track down all the commits related to these files. We just want to grab these files in their current state in the feature branch and drop them into the master branch. We could hunt down the last commit to each of these files and feed that information to git cherry-pick, but that still seems like more work than ought to be necessary.

Idea, the Second. How 'bout git merge --interactive? Sorry. That's not actually a thing. You're thinking of git add --interactive (which won't work for our purposes either). Nice try though.

Idea, the Third. Maybe we can just merge the whole branch using --squash, keep the files we want, and throw away the rest. Um, yeah, that would work. Eventually. But we want to be done with this task in ten seconds, not ten minutes.

Idea, the Fourth. When in doubt, pull out the brute force approach? Surely we can just check out the feature branch, copy the files we need to a directory outside the repo, checkout the master branch, and then paste the files back in place. Ouch! Yeah. Maybe, but I think we might have our Git license revoked if we resort to such a hack.

The Simplest Thing That Could Possibly Work

As it turns out, we're trying too hard. Our good friend git checkout is the right tool for the job.

git checkout source_branch <paths>...

We can simply give git checkout the name of the feature branch [1] and the paths to the specific files that we want to add to our master branch.

$ git branch
* master
  twitter_integration
$ git checkout twitter_integration app/models/avatar.rb db/migrate/20090223104419_create_avatars.rb test/unit/models/avatar_test.rb test/functional/models/avatar_test.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   app/models/avatar.rb
#   new file:   db/migrate/20090223104419_create_avatars.rb
#   new file:   test/functional/models/avatar_test.rb
#   new file:   test/unit/models/avatar_test.rb
#
$ git commit -m "'Merge' avatar code from 'twitter_integration' branch"
[master]: created 4d3e37b: "'Merge' avatar code from 'twitter_integration' branch"
4 files changed, 72 insertions(+), 0 deletions(-)
create mode 100644 app/models/avatar.rb
create mode 100644 db/migrate/20090223104419_create_avatars.rb
create mode 100644 test/functional/models/avatar_test.rb
create mode 100644 test/unit/models/avatar_test.rb

Boom. Roasted.

Notes

[1] git checkout actually accepts any tree-ish here. So you're not limited to grabbing code from the current tip of a branch; if needed, you can also check out files using a tag or the SHA for a past commit.

TextMate Oldie But Goodie Wrap-up

2008-12-02T00:00:00-05:00

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.

Grails vs. Rails: Are we seriously still talking about this?!

2008-11-18T00:00:00-05:00

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.

A Month of TextMate Productivity Tips

2008-11-04T00:00:00-05:00

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.

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.

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.

Testing Anti-Patterns Potpourri - Quotes, Resources, and Collective Wisdom

2008-10-07T00:00:00-04:00

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:

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.

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

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

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.

Audio, Video, Slides: How to Fail With 100% Test Coverage at raleigh.rb

2008-09-09T00:00:00-04:00

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.