やっぱりシンプルに。

上のエントリでも書きましたが、私自身は、テストコードはシンプルであるべき、複雑なテストコードは百害あって一利無し、と思っていますので、実は、上の様なテストコードはなるべく書かない方が良い、と考えています。
場合によってはアリ、とは思っていますけれど。

やっぱり、

$ cat test_iter_test.rb
require 'test/unit'
require 'iter_test'

class TC_DefineReader < Test::Unit::TestCase
  def setup
    # テストデータの配列を定義
    @test_data = [
      "* start line.\n",
      "# comment line.\n",
      "{ header start line.\n",
      "} header end line.\n",
      "/ separater line.\n",
      "[ block start line.\n",
      "] block end line.\n",
      "	 body line.\n",
    ];
    # イテレータに渡すパターンを定義
    @valid_regexp = /^[\{\}\[\]]/;     # valid.
    @invalid_regexp = /^[\{\}\[\]\s]/; # number of actuals more than expects.
  end

  def test_by_collect
    # 配列で一括確認する方法。

    # テスト対象のオブジェクト生成
    obj = Iter_Test.new(@test_data);

    # 期待値を一括照合してテストを実施。
    assert_equal([
      "{ header start line.\n",
      "} header end line.\n",
      "[ block start line.\n",
      "] block end line.\n",
    ],
    obj.get(@valid_regexp) { |l| l});
  end
end
$ ruby test_iter_test.rb
Loaded suite test_iter_test
Started
.
Finished in 0.140404 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

とかで宜しいのではないでしょうか。

但し、イテレータに渡したブロックの中で順次取得できる要素と、イテレータの戻り値となるコレクションとでは内容が異なることがあり得ます。
select, collect, each などが戻り値で返す要素のパターンが異なりますし、そもそもどの様にイテレータを実装するのかに依存しますよね。

それも含めて、より厳密なテストとするならば、ブロック内での要素の参照と、最終的に戻り値として取得されるコレクションの両方を確認すべきなのかもしれません。

Rubyist の皆さんは、どの様にテストされておられるのでしょう。