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...@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...@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
