Forum: Ruby Coming Soon...

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2007-02-02 12:08
(Received via mailing list)
Hi all - I normally don't like to blast the Ruby list w/ RSpec
news besides release announcements, but this will likely
be interesting to any of you who are interested in RSpec.

If you're not, then please save yourself some time and hit
delete now. Otherwise, read on, and thanks!


Dear spec'ers,

As many of you already know, we're gearing up for a pretty big 0.8
release of RSpec in the next couple of weeks. I'm writing in advance
because I want to give you a heads up about upcoming changes and how
they may impact your existing specs.

Two important things to note first:

1. We will provide a translator that you'll be able to use to convert
the majority of your existing specs to the new syntax before we remove
deprecated methods.
2. The syntax changes described below will be the last major changes
you'll see before a 1.0 release.

Here is the plan, though the time line is not yet clear.

== rspec-0.8.0-RC1

* Will be released within the next couple of weeks.
* Will be fully backwards compatible with
* Will also support all of the new syntax using expectation matchers
(see below).

Because this is such a significant change, we want to do a Release
Candidate first.

== rspec-0.8.x

Between 0.8.0 and 0.9.0, there will be at least one release that will
* A pre-0.8 to 0.9 translator.
* Noisy deprecation warnings that will let you know what methods will
be going and what you should use instead.
* A simple means of silencing those warnings (at your own peril!)

== rspec-0.9

* Will remove all of the old syntax.

Here are some answers to some questions that some of you may have:

== What is changing?

All of the should_xyz methods will be losing an underscore and gaining a


  actual.should equal(expected)
  actual.should_not equal(expected)

#equal, in this example, is a method that returns an expectation
which Ruby passes to #should, which then interacts with the matcher
to evaluate whether or not the expectation is met and report

All args to expectation matchers will require parens, and blocks must
be expressed
using curly braces. This has to do with ambiguity of arguments and
operator precedence. Don't worry, if you do the wrong thing you'll get
a warning. More on this below.

== Why this change?

The current syntax is supported by some very clever use of
method_missing. I'm allowed to say it was clever because I didn't
write it ;). At first it seemed awesome, but we've found that it
conflicts with other frameworks that use metaprogramming techniques to
late-bind to method_missing. So we had to make a choice between
rethinking RSpec's implementation or commit to a future of monkey
patching other frameworks as they introduce new uses of

Using expectation matchers means that we only need to add 4 methods to
#for expectation matchers

#for mocks/stubs

So it is much less invasive than it was before and, because we are not
using method_missing on YOUR objects, is much less conflict/error

It also supports a clear entry point to writing custom expectation
matchers, so if you have some domain-specific expectations like
"should travel_more" or "should get_a_raise", you'll have a very easy
means of doing so.

== Will there be any existing expectations that will no longer be
supported at all?

Yes, but only a few, and only related to RSpec on Rails. We will NOT
be supporting the following in the new syntax:


You will be able to use instead:

  response.should render_template
  response.should render_text
  response.should redirect_to

... but only after the action.

== For )(*&)(*'s sake, WHEN will you stop making changes like this?

Right now.

While we will not commit to 100% backwards compatibility, we on the
RSpec Development Team are as anxious for this to stabilize as you
are. We just feel that when we get to a 1.0 release we absolutely must
have an API that is solid, easy to use, stable and maintainable. We
just didn't see an end in sight to the problems we'd been seeing w/
the soon-to-be-ex-syntax, and we are very confident in this move and
its potential to fulfill those requirements.

== What's up w/ the parens and {} blocks?

Parens: When you do this:

  a.b c d

... Ruby gives you the all familiar:

  "warning: parenthesize argument(s) for future version"

If you can live w/ that, then have at it w/o the parens.

Curly braces: This has to do w/ precedence. do/end has a lower
precedence than {}, which means that in this expression:

  target.should satisfy do

... the block will be passed to #should instead of #satisfy. We need
the blocks to be passed to the matcher (#satisfy in this example), so
curly braces are required. This will be enforced by RSpec. When
#should or #should_not receive a block, the spec will fail with a
warning telling you to use {} instead of do/end. So you won't have the
opportunity to simply forget.

We're very excited about this release. I hope this email answers
most of your questions. If you have others, please
feel free, though I may punt on technical questions as many of those
will be answered by documentation in the 0.8.0-RC1 release.

Thanks for your patience with this and thanks especially to all of those
who contribute to RSpec's evolution by participating with this list and
submitting RFEs to the tracker.

David Chelimsky
on behalf of The RSpec Development Team
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2007-02-02 13:53
(Received via mailing list)
On Feb 2, 2007, at 5:05 AM, David Chelimsky wrote:

> == Why this change?

A very interesting and informative email and I don't even use RSpec.  ;)

Good luck with your new release.

James Edward Gray II
8e505c5c2f39afb259e31a040d051919?d=identicon&s=25 Klaus Ramelow (Guest)
on 2007-02-04 19:38
(Received via mailing list)
David Chelimsky schrieb:
> Dear spec'ers,
> deprecated methods.
> (see below).
> be going and what you should use instead.
I would prefere instead (as logical expressions): equal   /   not_equal
actual should not_equal(expected)

10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2007-02-04 20:42
Klaus Ramelow wrote:
> David Chelimsky schrieb:
>> Dear spec'ers,
>> deprecated methods.
>> (see below).
>> be going and what you should use instead.
> I would prefere instead (as logical expressions): equal   /   not_equal
> so:
> actual should not_equal(expected)

By grouping the not with the should, you are able to negate arbitrary
expectations.  If the not goes with the expectation, then each
expectation must provide its own negative (e.g. equal/not_equal,

-- Jim Weirich
74886c14aa167f34d39145d75c0b971c?d=identicon&s=25 Mushfeq Khan (Guest)
on 2007-02-04 20:53
(Received via mailing list)
Well, you can solve that problem by overriding method_missing on Object
that expectations that match the regex /^not_(.+)/ can be automagically

I'm kidding of course. I applaud this decision by the RSpec team. A
of Rails projects that I work on use RSpec and at one point, also used
Mocha. Some subtle bugs were cropping up due to clashes between the
libraries' use of method missing.

This topic is locked and can not be replied to.