If you want to learn ruby, there are a number of things I would recommend to get you started. However, this corse comes highly recommended from people I trust, and it’s free. Check it out

I’ve always liked the way RSpec succinctly clarifies the intentions of your tests in such a non-computer fashion so testing in fact turn into requirements gathering exercises. At Rubyconf last week David Chelimsky showed off some new syntax sugar that I absolutely loved. For all I know it could have been in RSpec from the start, but it was new to me and it’s now a regular part of my repertoire. It’s the pending block syntax.

The ability to mark tests as pending has always been a strength of RSpec over any other testing framework I’ve ever used. It’s easy enough to rename a test method so it doesn’t execute, but before RSpec I’ve never worked with one where you can mark it as pending and it then reminds you that you still have work to come back too. Too often renamed tests get forgotten. Here are the many ways to mark tests as pending.

1
2
3
4
5
6
7
8

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should make sure the second derivative of something calcs fine"

end

That will run with one green test, and one yellow test marked ‘PENDING: Not Yet Implemented’.

(That’s the output you get from Textmate’s most excellent spec runner). Another way to do the same thing, but add some context is as follows:

1
2
3
4
5
6
7
8
9
10

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should make sure the second derivative of something calcs fine" do
    pending "This test can't be implemented until derivatives make sense to me"
  end

end

It still marks the spec as pending, but instead of ‘Not Yet Implemented’, it gives the text you specified (in this case: ‘This test can’t be implemented until derivatives make sense to me’ - seemed like a good reason to me).

Both of these forms are very useful for marking entire specs as pending. I tend to use the first form when I’m first trying to capture all the specs I need to write to implement a piece of functionality. Then I come back and implement each spec, then get it passing, but I’ve already captured what I think would be the entire scope of functionality necessary in the pending specs. I’ve seen people use the second form (the pending keyword) a lot to skip a spec that is suddenly failing. There is a better way. Instead of marking the whole spec as pending, add a block to the pending keyword and use it to wrap the part of the spec that is misbehaving. You get a double benefit. Take the following test for instance:

1
2
3
4
5
6
7
8
9
10
11
12

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should follow the rules of basic arithmetic" do
    4.should be < 5
    9.should_not == 76
    3.should == (1 + 1)
  end

end

It fails as follows:

Ignoring the trivial nature of the spec, if the failing test is part of a library or in some code which you are dependent on somebody else to fix it. Take the failing spec, wrap it in a pending block with an appropriate comment like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

describe "Test some object with pending tests" do
  it "should make sure 2 + 2 = 4" do
    4.should == (2 + 2)
  end

  it "should follow the rules of basic arithmetic" do
    4.should be < 5
    9.should_not == 76
    
    pending "need to alter the rules of the universe to make this happen" do
      3.should == (1 + 1)
    end
  end

end

This produces:

Now, not only does the spec pass, you get a huge benefit. While it appears that the entire test is skipped as pending, it’s not. The specs outside the pending block are still evaluated and the spec will fail if any of their assumptions are broken. Another unexpected benefit is that the code inside the pending block is actually run with each spec execution. As soon as it passes, you’ll get an error notification saying that though you expected this spec to fail but it didn’t (in this case I modified the code to work, but you get the idea).

Consider it a friendly reminder to come back and clean up your pending specs as soon as they no longer need to be pending. That way you can stay lean and mean and keep those specs green.

If this is the first time you’ve seen RSpec in action, you don’t know what you’re missing. If you like to read up on cool stuff, head on over to the RSpec Homepage. If you’d rather sit back and let some smart person explain it to you and show you how to get it all set up, I’d say this would be a better bet.

Enjoy!