This is a very isolated unit-testy.  While I often favor that approach in testing applications, within RSpec I prefer to do full integration tests of the features as users use them.  The normal main downside to full integration tests is that their slow...but they are blazing fast here in RSpec (rspec-mocks' tests take about 500 ms total), and testing this feature entirely via the public API users use has two huge benefits:

* It gives us *much* greater confidence the feature works.
* It makes it *much* easier to refactor in the future.  IMO, `ReceiveMessageChain` is entirely an implementation detail of this feature.  I want to be free to refactor that entirely, while retaining tests that tell me if the feature is still working.  Having tests that use `ReceiveMessageChain` directly inhibits such refactorings.

Just to give you an example of one integration bug that's not (and can't) be caught by these tests: if you look at the implementation of `StubChain.stub_chain_on`, you'll notice that it relies on `Object#stub`, which, if the user has disabled the `should` syntax, will raise a `NoMethodError`.  The tests here are incapable of detecting such an integration error.