> Half of the examples are irrelevant to the eventual bug, so I could drop
them but we didn't prove they worked anywhere else which has bugged me in
the past so also open to refactoring...

It's unclear to me how testing `reset` would not prove it works anywhere?

Anyhow, thinking about this some more, I think what bugs me here is that it has so much supporting code to define and run the examples, and so little substance, that the signal-to-noise ratio is very low.  It could be greatly improved if the supporting code is pulled  out into a shared context.  Then it would be re-usable as well, and keep the examples here focused on the the stuff you're spec'ing.

BTW, I think I just realized a potential bug in your spec: it looks like you are dependent on the order the examples run, right?  I mean that this example:

``` ruby
expect(SubClass.new.foo).to eq('bar')
```

...needs to run after this example:

``` ruby
SuperClass.any_instance.stub(:foo)
SubClass.any_instance.stub(:foo).and_return('baz')
expect(SubClass.new.foo).to eq('baz')
```

...for it actually to be testing anything.  However, given that we've configured rspec to run specs in random order, this order is not guaranteed.  In contrast, if you tested this like so:

``` ruby
SuperClass.any_instance.stub(:foo)
SubClass.any_instance.stub(:foo).and_return('baz')
expect(SubClass.new.foo).to eq('baz'

reset_all # this needs to be added to VerifyAndResetHelpers

expect(SubClass.new.foo).to eq('bar')
```

...it does things in the necessary order, and doesn't have the noise of all the example group/example/reporter setup.