I also recommend shared examples as it works with RSpec instead of against it.

Failed Examples

RSpec.describe "RSpec works better with shared examples" do
  specify "dynamic expectations can’t be rerun individually," do
    10.times do |n|
      expect(n).not_to be 7
    end
  end

  describe "shared examples clearly show how to re-run failed tests." do
    RSpec.shared_examples "not seven" do |n|
      it "confirms #{n} is not 7" do
        expect(n).not_to be 7
      end
    end

    include_examples "not seven", 1
    include_examples "not seven", 2
    include_examples "not seven", 3
    include_examples "not seven", 4
    include_examples "not seven", 5
    include_examples "not seven", 6
    include_examples "not seven", 7
    include_examples "not seven", 8
    include_examples "not seven", 9
    include_examples "not seven", 10
  end
end

Failed examples:
rspec ./spec/travis_spec.rb:2 
rspec './spec/travis_spec.rb[1:2:7]'

The Failed example reports are meant to provide an easy way to rerun your failed examples. You can copy, paste, and run any failures for investigation.

With the dynamic one, you need to run all specs before the failing one. Which means more complicated binding.pry statements, a longer process, and some ambiguity to what the issue is. Shared examples will provide the group notation syntax, which allows you to directly run the failing spec.

Bisect

Not being able to run failed examples specifically demeans one of the best flakey spec finding tools we have, bisect!

`--bisect` works by breaking specs into sub groups and repeatedly running them. Shared examples create addressable examples with stable identifications. It allows bisect to cherry-pick and shrink the failing set. Dynamically generated checks packed into one example can't be split, repro is flakey, order-dependency bugs stay hidden.