rspec/rspec-expectations — pull request #129 by myronmarston (2012-04-01 01:53:38+00:00)
Title: Yield matchers

I still need to write cukes for these, but I've gotten things to an almost-ready-to-merge point so I wanted to solicit feedback. A few questions/comments:

* Did I make the right decision about how to handle `instance_eval`?
* Given the non-standardness of block parameter in the `expect { |b| meth(&b) }` syntax, I thought it good to give people helpful errors if they forget this. I'm also thinking that we could detect whether or not `to_proc` is called on the block parameter, and, if not, raise an error instructing users they need to pass it on as `&b` for the matchers to work properly. Thoughts? Will that get annoying or be helpful?
* 3 of the 4 matchers are not really designed to be used with multiple-yield/iterator style methods. Only `yield_successive_args` is designed for that case. How should the other 3 matchers behave when used with a method that yields multiple times?
* Is the argument matching intuitive, or is it too complex? Matching using only `==` seemed to restrictive to me, and I like the semantics of `===` for this kind of thing...except for the fact that that when used with classes, it's only true for instances of that class, and not for the class itself, so something like `expect { |b| ORM.each_subclass(&b) }.to yield_successive_args(User, Post, Comment)` would fail unexpectedly.
* I realized that there's not a good clean way to specify that a method yields multiple times with no arguments. Would that ever be useful/needed? If so, we may want to augment the single-yield matchers with "# of times" modifiers, e.g. `yield_control.exactly(3).times`.

/cc @dchelimsky @justinko @mattwynne @zdennis