達人プログラマのDavid ThomasがShouldaを分かりやすく紹介してくれていたので、仮訳してみたよ。
（翻訳・公開することを快く承諾してくれました。）

英語が苦手なので間違いもあると思います。指摘してくれると嬉しいです。

オリジナルの記事：Shoulda used this earlier

—– ここから —–

Shoulda（もっと早く使っていれば）

色んな意味で、ソフトウェアをテストすることは、外に出て運動をすることに似ている。しなきゃいけないことは分かってるし、運動は自分を良い状態にしてくれるのは分かってるんだけど、それをやらない言い訳を考えるのもすごく簡単だ（明日、今日の分もやるよ）。

だから、テストをやりやすくするものは何だって良いことだ。だって、やらない言い訳を減らしてくれるからね。

昔ながらのxUnit-styleのテスティングフレームワークについて、絶対好きになれないことのひとつは、セットアップとティアダウンの構造だ。これらのフレームワークでは、テストケースはひとつのクラスで、セットアップとティアダウンはそのクラスのメソッドとして実装される。ひとつひとつのテストもメソッドだ、だから基本的な流れは、こんな風になる。

  for each test method in the class
    run setup
    run the test method
    run teardown
  end

ナイス・アンド・シンプル。すべてのテストメソッドは、セットアップメソッドによって作られた標準環境の恩恵を受ける。そして、ティアダウンメソッドは、後で片付けの仕事をしてくれる。

こんなとき以外は・・・私がテストを書くときは、私はいつもたくさんのシナリオをセットアップしたくなる。A and B and Cをやりたい。それから、A and Bだけどnot Cの場合。それから、A and not B。それから、A and D。などなど。たくさんのテストケースのクラスを書くにはふたつの方法がある。共通のセットアップの実行を継承したサブクラスを使う方法、または、テストメソッドごとにセットアップコードを書く方法だ（多くの場合、ヘルパーに取り出す）。結局、私はほとんどいつも後者をやる。そしてそれは退屈で、しかも、セットアップコードのおかげで、それぞれのテストが見にくくなってしまう。

実は、RSpecに浮気したんだ。specフレームワークが私の求めているものを持っているみたいだったから。だけど、RSpecを使うのは楽しめなかった。（猫好きか、犬好きか、みたいなものだと思う。）

そこで、Shouldaですよ。

そんなとき、2週間くらい前だけど、Mike ClarkとChad Fowlerがshouldaを紹介してくれたんだ。Shouldaはテストのフレームワークじゃない。そのかわり、Shouldaは、RubyのTest::Unitフレームワークを、テストコンテキスト（文脈）の考え方で拡張してくれるんだ。ひとつのコンテキストは、共通点を持っているテストメソッドを集めたテストケースの一部分だ。最も簡単な場合、コンテキストは、単に注釈のための道具として使える（うん。これはくだらない例だけど）：

context "My factorial method" do
  should "return 1 when passed 0" do
    assert_equal 1, fact(0)
  end
  should "return 1 when passed 1" do
    assert_equal 1, fact(1)
  end
  should "return 6 when passed 3" do
    assert_equal 6, fact(3)
  end
end

単にセットアップブロックを書くだけで、コンテキストの中のものは共通のセットアップコードをシェア（共有）することができる。

class CartTest < Test::Unit::TestCase

  context "An empty cart" do
    setup do
      @cart = orders(:wilmas_empty_cart)
    end

    should "have no line items" do
      assert_equal 0, @cart.line_items.size
    end

    should "have a zero price" do
      assert_equal 0, @cart.price
    end
  end

  context "Some other context..." ...
  end
end

という訳で、ひとつのテストケースの中で、複数のコンテキストをセットアップできるし、それぞれのコンテキストは、固有の環境を持つことができる。

待てよ、私の元々の問題に戻ろう。私はよく、関連するテスト環境のヒエラルキー（階層）をセットアップしたくなるんだった。Shouldaのコードはこれを素晴らしいやり方で処理してくれる、なぜならコンテキストをネストさせてくれるからだ。例えば、支払い時に、クレジットカードの処理で、住所間違いで弾かれ、その後、住所を修正して承認された場合、何か追加の情報を顧客に提供する機能だ。私は２つのテストをしたい。最初のアドレス間違いがなかった場合とアドレス間違いがあった場合だ。

この環境をセットアップするために、ショッピングカートをセットアップする必要がある。支払いへのダミーの応答をつくらなきゃいけない、それからアプリケーションへのレスポンスをpostしなきゃいけない。最初のアドレスが間違っていた場合、応答を生成するより前に、その注文に関する処理に、その間違い項目の注入もしたい。

shouldaを使えば、簡単にネストされたコンテキストを作ることができた。最上位のコンテキストは共用のセットアップを行う。内側のコンテキストは、その後、そのコンテキスト内のテストのために適切な環境のセットアップをおこなう。こんな風に：

  context "Checking out"  do
    setup do
      @cart = cart_named(:freds_full_cart)
      @cart.prepare_for_store_authorize!
      @params = approved_authnet_response(@cart)
    end                  

    context "with no AVS errors in CC transaction history" do
      setup do
        post :post_from_authnet_authorize, @params
      end

      should_redirect_to "{:action => :receipt}"
    end 

    context "with AVS errors in CC transaction history" do
      setup do
        avs_error = CcTransaction.new(:response_code => 2, :response_reason_code => 27)
        @cart.cc_transactions < :explain_avs_mismatch}"
    end
  end

外側のセットアップは、内側のコンテキストのどの実行よりも前に実行される。そして、内側のコンテキストのセットアップは、そのコンテキストを実行する時に、実行される。そして、Shouldaは、それをすべて追跡しているので、アサーションが失敗したときには、とても自然なエラーメッセージを得ることができる。例えば、上の２番目のコンテキストの中のテストが失敗した場合は、次のようなエラーメッセージが得られる。

Checking out with AVS errors in CC transaction history should
redirect to "{:action => :explain_avs_mixsmatch}".

という訳で、私はやっとテスト環境のヒエラルキーをセットアップすることができるようになった。画期的って訳じゃない。テストしない言い訳を減らすひとつに過ぎないけれど・・・

—– ここまで —–

その他、Rubyでのテストについて、役立ちそうな記事へのリンクを置いておきます：

スはスペックのス〜RSpec(関西弁)の動画 by 角谷HTML化計画
RSpecよりShoulda、fixturesよりヘルパーとMocha by Unexplored Rails
shouldaをインストールしてみる by んばぁってなんなのよ

仲良くしてください。