Diff of Range objects is less useful than default RSpec output

[owst]

When an expectation that two Range objects are equal is violated, the super_diff output hides the values within the Ranges:

     Failure/Error: expect(actual).to eq(expected)

       Expected #<Range:0x00007ff9338559b0> to eq #<Range:0x00007ff933855988>.

       Diff:

       ┌ (Key) ──────────────────────────┐
       │ ‹-› in expected, not in actual  │
       │ ‹+› in actual, not in expected  │
       │ ‹ › in both expected and actual │
       └─────────────────────────────────┘

         #<Range:0x00007ff9338559b0 {
         }>
     # repro.rb:20:in `block (2 levels) in <main>'

which makes it hard to diagnose the cause as you can't see the values within. The default RSpec formatter makes it clear:

     Failure/Error: expect(actual).to eq(expected)

       expected: 1..20
            got: 1..10

       (compared using ==)

       Diff:
       @@ -1 +1 @@
       -1..20
       +1..10

     # repro.rb:20:in `block (2 levels) in <main>'

would it be possible to change the super_diff output to show the values within the Ranges?

A standalone reproduction script:

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'

  gem 'rspec', "= 3.11.0"
  gem 'super_diff', "= 0.9.0", require: false
end

require "rspec/autorun"

# Uncomment the next line to see less-useful output
# require "super_diff/rspec"

RSpec.describe "Range comparisons" do
  it do
    actual = (1..10)
    expected = (1..20)

    expect(actual).to eq(expected)
  end
end

Thanks,
Owen.

[mcmire]

Thank you @owst, that definitely seems like a legitimate bug (I encountered a similar issue yesterday myself). I'll take a look when I get a chance!

[jas14]

We're falling back on the DefaultObject differ; this should just be a matter of introducing an inspection tree builder + operation tree builder that handle Range objects specifically. See #259 for a very similar fix that added handling for Data objects. This would be a good first issue!

[owst]

Oh, I hadn't noticed that @lucaseras had already created a very similar PR as I was about to 🙌

@jas14 should this issue be closed?

[jas14]

It should! I thought it had been automatically, sorry about that and thanks for highlighting.