This actually happened to me today. I got on the elevator to head up to Relevance World Headquarters, wearing my dress-up clothes (it included long pants). I was also wearing my hard shell backpack, protecting, as it always does, my preci^{h^h}h^hHlaptop. The elevator stopped at the second floor and let on a silver-haired gentleman of about 60 years, wearing a quite fly three-piece suit. I nodded, said ”’morning”, and he returned the salute.

We stopped at the fourth floor (RWHQ, as previously mentioned) and my companion was on his way to the fifth floor. As I exited, I uttered the standard “have a good day”. As I rounded the corner, and the elevator doors were closing, his ringing, stentorian voice carried into the hallway: “Nerd,” he said. “What a nerd.”

I was, quite literally, too stunned to even respond. The doors closed on my elevating friend and I couldn’t even muster enough clear thought to rush the stairs and meet him on the fifth floor. I suppose its possible the poor man had Tourette syndrome. Or, maybe he was wearing an Obadiah Stane inviso-earpiece and was talking to somebody else. But, most likely, I got called a “nerd” by a dude in a suit in my own elevator.

As my daughter would say, “for real”.

I was talking to Tim the other day about auditing Rails projects, and how we see a lot of Rails projects that reinvent the wheel instead of using plugins. The obvious follow-up question, of course, is "What plugins (or gems) should we be using?" Below I list ten plugins that we use regularly, and a brief reason why you might want to, too.

• fixture_replacement2: fixtures are difficult to maintain. There is no "one size fits all solution," but we have found this to be a big help.
• tarantula: A single test can find a lot of bugs, if that single test visits every link in your app, tries to submit bad data, and polices your output HTML.
• test_spec_on_rails: specs are better than tests.
• permalink_fu: meaningful URLs for your objects.
• safe_erb: don't trust external data!
• unit_record: get the database out of your unit tests. 1000s of tests can run in seconds.
• restful_authentication: clean, simple authn.
• multi-rails: test your code against multiple versions of Rails in a single rake task.
• attachment_fu: most apps need attachments eventually.
• exception_notification: find out by email when things go wrong.

Many of these plugins have alternatives (e.g., you could use rspec instead of test_spec, or nulldb instead of unit_record). Regardless of which plugin you pick, make sure you think about the features provided by the plugins above, and don't reinvent the wheel.

Notice that most of these plugins are already in git, so forking them is easy. If you see something that needs improvement, jump in and do it! While reinventing the wheel is bad, improving the wheel is most welcome.

[6/18/2008: updated to include github url for fixture_replacement]

The Refactotum tutorial out at RailsConf went really well. We know that a lot of folks submitted their patches based on the work done in the tutorial, but Nicholas is the first to email us their committed and accepted patch. Way to go, Nicholas!

If anybody else has a patch that made it out (to any project) from their Refactotum work, we’d love to hear about it. Drop us a line or add a comment.

Thanks to everyone who came out to the tutorial. We had a blast, and we hope we achieved something for the community.

Get the updated code sample here. It turns out that my MacBook Pro somehow compressed a cached version of the samples that were missing several key directories. I’m not sure how that worked, but here is the updated, full version.

Question: What is unusual about this test?

expect false do
  validation = Validatable::ValidatesLengthOf.new 
               stub_everything, 
               :username, :maximum => 8
  validation.valid?(stub(:username=>"usernamefdfd"))
end

Answer: They are anonymous. Jay Fields has written about why this might be a good idea, and included feedback from a bunch of people who care about this kind of thing.

The example above is from tests in Jay's validatable library. Here is a modified version of the same test:

account = Struct.new(:name)
expect false do
  validation = ValidatesLengthOf.new account, 
               :name, :maximum => 8
  validation.valid?(account.new("this string is too long"))
end

The modified version changes several things:

• Rather than a stub, a named struct makes the test look more like a real-world usage.
• Including Validatable at the top of the module (not shown) keeps namespaces out of the test.
• Test strings can have values that name their purpose, e.g. "this string is too long".

Much food for thought here. How would you answer these questions?

• Do you prefer the stub or the struct version? Do anonymous tests change your ideas about when to stub? How?
• Struct.new is more typical of real-world usage than a stub would be. A named class would be even more typical. Why would using a named class be a bad idea in languages like Ruby and Java, and what features would a language need to fix the problem?
• Do the string names make the test more readable? Do they re-introduce the problem Jay was solving in the first place?