What are the benefits of rspec matchers versus vanilla ruby?

Question

All tutorials on rspec use built-in matchers but I do not see the benefits given the cost of learning new syntax. For example, these two are equivalent:

expect(person.name).to eq "John" 
person.name.should == "John"

At least eq is something easy to remember. rpsec involves many more "exotic" things like have(n).things. Why shouldn't I use object.size.should == n in plain ruby instead?

In sum, what's the benefit of learning all these rspec matchers over using .should ==?

Answer 1

.should is not vanilla ruby - it is rspec just like expect...

rspec introduced the expect syntax, because of inherent caveats in the should method:

Delegation Issues Between method_missing, BasicObject and the standard library’s delegate, ruby has very rich tools for building delegate or proxy objects. Unfortunately, RSpec’s should syntax, as elegantly as it reads, is prone to producing weird, confusing failures when testing delegate/proxy objects.

Rspec API guidelines is to have tests read like english, that is why they have syntax like:

 object.should have(5).elements

Or with the new syntax

expect(object).to have(5).elements

Which means that you "expect object to have 5 elements", instead of having to explain the same this with

object.size.should == n