Old style: a.should == b
New style: expect(a).to eq b

I've recently converted all my gems over to use the expectation syntax and have been writing specs that way ever since: github.com

I don't plan on switching back any time soon. How about you? Have you converted your old specs to the newer syntax? Are you planning on sticking with the old syntax? Which do you prefer and why?

I haven't worked on a project that exclusively uses the new `expect` syntax yet, but we're planning to convert some of our projects at work over soon (it's been hard to find time before now to do the conversion).

I do prefer the `expect` syntax -- there are fewer gotchas and surprises compared to `should` and I'm of the opinion that gems generally shouldn't do monkey patching unless that is their core purpose (e.g. activesupport). I'd like to get RSpec to a state where it is examplary in that regard, while still sporting an expressive DSL.

What's an example of a gotcha in the older syntax?

My blog post[1] explains a major one: proxy objects can cause confusing failures, since they will proxy the `should` and `should_not` through to the target object, even when you are trying to test a decorated aspect of the proxy itself. In general, `should` and `should_not` rely on the those methods being available and acting consistently on every object in the system, but RSpec does not own every object in the system and cannot ensure that.

Another gotcha: with `should` you can use it in any context, including production code. Meaning you might move a spec helper method into prod code, have a passing test suite, then
get `NoMethodErrors` in production due to accidentally using `should` in that context.

[1] myronmars.to

With all of this, I can see how `expect` would be a wiser way to approach testing than through monkey patching, however I do have one question.

We commonly use `it { should == 'something' }` with a `subject { Object.new }` block of some kind defined for a beautiful DSL. How does the new `expect` syntax factor into this, or does it at all?

I haven't used the new syntax very much, but I like the thought of it, at least. I'll probably be using it for new projects.

I do not like it {should == 'something}

The it { should == 'something' } was always such a beautiful expression of what I wanted to test. However, for reasons that have already been expressed, the expect().to syntax is definitely a winner in my mind and I am looking forward to using it consistently in future projects.

One downside of switching to the expect syntax is that there's no replacement for should_receive/should_not_receive. I suppose I could alias those methods to expect_to_recieve/expect_not_to_recieve in my spec helper but it seems like it should be built-in for consistency.

It would seem a natural fit to write something like expect().to_receive and expect().not_to_receive. That would fit with the new syntax perfectly!

Re: `it { should ... }` one-liners: we briefly discussed finding an alternative [1], but `should` in that context is not the one that's globally available on every object, so it doesn't suffer from the same problems. If you want a one-liner syntax that corresponds to the `expect` syntax, there's a simple, safe way you can add it [2], but we don't plan to add this to rspec-core anytime soon, if ever. I personally use the one-liner syntax very rarely.

[1] github.com
[2] stackoverflow.com

Erik/Matt - We've been talking about using the new syntax for rspec-mocks for a few months [1], but there are a number of open questions/concerns that need to be resolved first. I'd love your feedback to help figure this out. The issue thread is long, so I'll try to summarize:

* `expect` is great for mock expectations, but what about stubs? `expect` makes no sense. The current contender is `allow` (e.g. `allow(a).to receive(:foo).and_return(5)`), but it reads quite awkwardly when dealing with a partial mock object that already responds to that message.

(to be continued...)

[1] github.com

Block implementations have a gotcha:

expect(a).to receive(:foo) do |arg|
# do something with arg
end

Here the block binds to `#to`, not to `#receive` as you might expect, due to the precedence rules of ruby. We could forward the block from `to` to `receive` but one of my goals here is to move RSpec towards less magic, not more. Or users could just use curly braces for the blocks...but that's not the normal form most rubyists use for a multiline block.

Another issue: while consistent syntax is nice, these two things have quite different semantics:

expect(a).to pass_some(:matcher)
expect(a).to receive(:some_msg)

The first is a normal expectation/assertion, and will potentially cause the example to immediately fail. The second looks identical syntactically, but is quite different: it will never fail the example at that point, but sets up an expectation that will be checked at the end of the example.

Generally, it's good for things that behave the same to look the same and things that behave different to look different...so this is a concern of mine. (Not a deal breaker, of course, but it's worth discussing).

Another variation on this syntax we've discussed is something David came up with (see [1] and following comments) is using `on` as the wrapping method:

on(obj).expect(:msg).with(arg1, arg2)
on(obj).stub(:mgs).with(arg1, arg2)

I like this quite a bit (I'd really like to get RSpec down to zero global monkey patching of Object), but others seem not to like it. For a change as large as this, I'd really like to have broad community support.

As you can see, it's hard to find a perfect syntax for this :(

Anyhow, if you guys have any suggestions, I'm all ears!

[1] github.com

I really like the goal of getting RSpec down to zero monkey-patching on Object.

The on(obj).stub(:msg) seems to be along the lines of what I would use. Since expect() is already being used on mock objects, I think using it as a was to stub as well would be confusing.

Yes, it does read funny unless you get it just right, but on(obj).stub(:msg) seems very close in my opinion.

@Matt - can you share your thoughts on the github issue? Would be nice to keep the main discussion there (especially since others there are monitoring the conversation).

@Myron, sure! I somehow was blind to that fact.

I'm in Jasmine a lot so the new syntax keeps my mind straight when going between Jasmine and Rspec.