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

Myron Marston myron.marston at gmail.com
Sun Dec 1 01:34:28 UTC 2013


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, dchel... at gmail.com 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
>> rspec... at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20131130/063d05c3/attachment.html>


More information about the rspec-users mailing list