[molf]

I can't believe this line is considered good practice:

    collection.should have(2).items

It illustrates what I believe is wrong with RSpec: the assertion style is completely disconnected from the API that is being tested. There's no way you can tell what methods are being called on the `collection` object without being intimately familiar with this specific RSpec matcher.

So what does that line actually do? Apart from calling strange methods like `items` on strange objects like `have(2)` in the end the test passes iff `collection.length` equals 2. Compare RSpec with classic test/unit assertions:

    collection.should have(2).items

    assert_equal 2, collection.length

The second line is just so much more obvious to me.

On the other hand I really like the RSpec way of grouping tests and structuring test cases. My favourite test cases are written with minitest/spec (a lightweight test/unit-compatible clone of RSpec) and test/unit-style assertions.

[reyan]

In fact RSpec team is in the process of changing the default to the new expect matcher syntax (http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectatio...).

[graywh]

Then write

    collection.length.should eq(2)

But I see nothing wrong with the other once you know how the "have" matcher works. It will even let you write

    it { should have(2).items }

when your subject is set up properly.

[nirvdrum]

Likewise, what most people really care about is the delta. Absolute matches work when the initial state is 0, but it's fun watching these sorts of tests fail when that's not the case.