These examples are very focused on specifying how this matcher responds to the matcher protocol, which works OK, but I tend to favor examples that simply use the matcher as an end user would.  For example:

``` ruby
module RSpec
  module Mocks
    describe HaveReceived do
      describe "expect(...).to have_received" do
        it 'passes when the double has received the given message' do
          dbl = double_with_met_expectation(:expected_method)
          expect(dbl).to have_received(:expected_method)
        end

        it 'fails when the double has not received the given message' do
          dbl = double_with_unmet_expectation(:expected_method)

          expect {
            expect(dbl).to have_received(:expected_method)
          }.to raise_error(/expected: 1 time/)
        end
      end

      describe "expect(...).not_to have_received" do
        it 'passes when the double has not received the given message' do
          dbl = double_with_unmet_expectation(:expected_method)
          expect(dbl).not_to have_received(:expected_method)
        end

        it 'fails when the double has received the given message' do
          dbl = double_with_met_expectation(:expected_method)

          expect {
            expect(dbl).not_to have_received(:expected_method)
          }.to raise_error(/expected: 0 times.*received: 1 time/m)
        end
      end
    end
  end
end
```

It still tests `failure_message`, `negative_failure_message`, `matches?` and `does_not_match?` by executing all these methods but treats the as an implementation detail (as I would consider them).

Is there any reason you prefer the approach you've followed here?