[rspec-users] May expect { ... }.to_not be changed to expect { ... }.not_to?

[Takumi Tsunokake]

Hi, I'm Takumi Tsunokake.

I think
expect { ... }.not_to rails_error
is more grammatical and natural than
expect { ... }.to_not rails_error

Are there any backgrounds and reasons of decision for expect
{ ... }.to_not, not expect { ... }.not_to?

I'm happy if expect { ... }.to_not is changed to expect
{ ... }.not_to.

Best Regards :)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Takumi Tsunokake
http://d.hatena.ne.jp/bekkou68/
@bekkou68
_______________________________________________
rspec-users mailing list
rspec...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky]

On Sep 7, 2010, at 10:35 PM, Takumi Tsunokake wrote:

> Hi, I'm Takumi Tsunokake.
>
> I think
> expect { ... }.not_to rails_error
> is more grammatical and natural than
> expect { ... }.to_not rails_error

I think you mean raise_error (I've made the same mistake a few times). I'm pretty sure they're equally valid, grammatically speaking:

Expect x not to y
Expect x to not y

> Are there any backgrounds and reasons of decision for expect
> { ... }.to_not, not expect { ... }.not_to?
>
> I'm happy if expect { ... }.to_not is changed to expect
> { ... }.not_to.

It's because it aligns better with should[_not]. I think it would be more confusing if we had [not_]to and [should_]not.

HTH,
David

[Sergio Lapenna]

So, what we should use? 'not_to' or 'to_not'?

[Myron Marston]

Use which ever you prefer.  One is an alias for the other.  In my experience, I've found that `not_to` reads more naturally sometimes, and `to_not` reads more naturally sometimes (for purely subjective reasons).  My advice is to use whichever comes out naturally when you are writing your expectations and not worry about which is more "correct" or "recommended".

Myron