Technical Pickles

I have been generally using RSpec for my testing needs, but I've recently been persuaded to use Shoulda on a few projects.

For most things, they seem about on par.

One thing I missed in particular was the 'should' syntax of RSpec, like:

x.should == 42

As opposed to using test-unit's:

assertEqual 42, x

I haven't been able to entirely quantify why I prefer the former syntax, but I think it has to do with more succinctly expressing the assertion.

While I haven't found quite to replace that style syntax, I do have something that fits my craving: assert {2.0}. This gives us something like:

assert {x == 42}

I think I'm actually digging this over the other two styles, because:

• If you can come up with an expression, you can assert it.
• Nice output when the assertion fails.

So I think I've discovered Shoulda's secret sauce, the reason why you should use it.

Macros.

It's nice and all to have a decent syntax for doing nested contexts, and declaring tests. But the real power comes from having macros that define tests for you.

Here's a fully shoulda-ified model test (from an example on the Shoulda website):

class PostTest < Test::Unit::TestCase
  load_all_fixtures

  should_belong_to :user
  should_have_many :tags, :through => :taggings

  should_require_unique_attributes :title
  should_require_attributes :body, :message => /wtf/
  should_require_attributes :title
  should_only_allow_numeric_values_for :user_id
end

Imagine how much more code you'd have if you were to do this by hand.

It's not magic though. It's pretty easy to write your own. To start with, you can just define them in your test_helper.rb.

Here's the jist of what you do:

• Define a class method, usually like should_something_something, or maybe something_should_something.
• In this method, declare a should block. You'd probably want to name this dynamically based on the parameters given to your method.
• Assert stuff.
• ...
• PROFIT!

As an example, here's something I wrote recently:

class Test::Unit::TestCase
  #snip
  def self.should_build_request_path(path)
    should "build request path of #{path}" do
      assert {path == @api_call.build_request_path}
    end
  end
  # snip
end

Then in your tests, you can use it like:

class GetTagsCallTest < Test::Unit::TestCase
  # snip
  should_build_request_path '/v1/tags/get'
  # snip
end

It's pretty straightforward stuff.

If you start to get a lot of these in your test_helper.rb, you can always move them into module, include/extend them. If they are general enough, who knows, maybe release it as a gem.

I've been using Shoulda on a few projects recently, and have done a few posts on it as well.

Last week, I came across this talk by Tammer Saleh by way of GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS .

Tammer is the author of Shoulda, and hearing him talk about it definitely gave me some insight into Shoulda and how to use it.

If you hadn't heard, GitHub went officially live last week.

As I've posted before, git is pretty awesome. GitHub makes it even better.

In honor of the launch, here's a quick rundown of forking a repository to start hacking away.

First off, you need to find a victim. In this case, I'm going to go after thoughtbot's Shoulda.

First navigate to the repository, and click 'fork'.

Give it minute while the hardcore forking action happens. Now you have your own fork of the repository.

Here you can see your clone/push URL. So we should go ahead and clone it:

git clone git@github.com:technicalpickles/shoulda.git

So we have a checkout now. As is, it's kind of detached from the official repository. If we're going to be actively working on it, we should add the official repository as a remote.

cd shoulda
git remote add official git://github.com/thoughtbot/shoulda.git

From now on, we should be able easily pull in the changes:

git pull official master

So now what? Get hacking of course. But how do send our changes back? Well, this is a tricky question. There are several ways, but it mostly depend on those receiving the changes back. As people get more comfortable with git, I think we'll start to see some best practices emerge here.

After forking the recently gitified Shoulda, I started poking around. First thing I noticed is tests were failing because some directories were missing. Presumably, this is because git ignores empty directories.

Let's use this opportunity to using git and GitHub to contribute a fix for this, shall we?

Here's a sky high view of the process:

• Create a fix branch
• Make changes
• Push fix branch to GitHub
• Browse to branch in browser
• Submit a 'pull request' to the maintainer for review

After the maintainer gets the request, they are free to do as they see fit. Accept it, tweak it, kick it, and so on.

Fixing it

First thing's first. We should create a branch off of master to isolate the fix:

git checkout -b add_missing_dirs

Now the tricky part: actually fixing it. When everything is ready, I just commit it:

git commit

As always, it's good to include meaningful commit messages. Keep in mind that if accepted, this message will become eternally bound to the repository.

With that out of the way, we actually need to push it to our 'origin' remote. This would be GitHub.

git push origin  add_missing_dirs

Requesting the pull

We can now go to our repository on GitHub. We want to browse to the add_missing_dirs branch. Mouse over 'all branches' to get there.

This gets us to the branch. Next, we indicate our desire to submit a pull request.

This prompts us for some details. I only had one commit, so I used its log as the message. I added tsaleh aka Tammer Saleh as the recipient, since he's the maintainer of Shoulda.

After you submit, you'll get a notice that it was sent successfully, and you'll be returned to your branch. The recipients now get a notice about this pull request, and can take appropriate action from there.

Done and done

Congratulations! You are now at the mercy of the maintainer.

Last Tuesday, we had a small, but dedicated showing at the Hackfest:

• Dan Croak
• Tom Shealy
• Josh Nichols

Going in, we didn't really have a something in mind to work.

We thought to pick up the app we started in merb for organizing katas. But when it came down to it, we figured it'd be a lot quicker if we just did it rails.

We actually wanted something a little more general, kind of a one stop shop for Boston Ruby stuff. Here's what we wanted:

• Keep track of events (meetings, hackfests, and katas)
• Projects that have come out of above-mentioned meetings
• Recent commits from these projects

Tools we used:

• rails
• shoulda
• haml
• blueprint css
• feed-normalizer

You can see the code we ended up with in the hackfest repository.

Or, you can see it in action.

For simplicity's sake, we didn't initially bother with users/permissions/etc, so be gentle with it.