May expect { ... }.to_not be changed to expect { ... }.not_to?

Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

May expect { ... }.to_not be changed to expect { ... }.not_to?

bekkou68
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
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-users
Reply | Threaded
Open this post in threaded view
|

Re: May expect { ... }.to_not be changed to expect { ... }.not_to?

David Chelimsky-2
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
_______________________________________________
rspec-users mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-users
Reply | Threaded
Open this post in threaded view
|

Re: May expect { ... }.to_not be changed to expect { ... }.not_to?

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

On Saturday, November 30, 2013 5:28:54 PM UTC-8, Sergio Lapenna wrote:
So, what we should use? 'not_to' or 'to_not'?

On Tuesday, 14 September 2010 04:13:45 UTC+2, [hidden email] wrote:
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
_______________________________________________
rspec-users mailing list
[hidden email]
<a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Frubyforge.org%2Fmailman%2Flistinfo%2Frspec-users\46sa\75D\46sntz\0751\46usg\75AFQjCNFTJTbX426JF36MfVEx9dW_7QF8Rg';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Frubyforge.org%2Fmailman%2Flistinfo%2Frspec-users\46sa\75D\46sntz\0751\46usg\75AFQjCNFTJTbX426JF36MfVEx9dW_7QF8Rg';return true;">http://rubyforge.org/mailman/listinfo/rspec-users


_______________________________________________
rspec-users mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/rspec-users