3 ms·

Unfortunately this style of assertions will lead to warnings in your test cases. I find many RSpec projects run their tests without warnings enabled because of

Unfortunately this style of assertions will lead to warnings in your test cases. I find many RSpec projects run their tests without warnings enabled because of this issue. I MADE A VIDEO WITH FUN MUSIC TO DEMONSTRATE! :D :D http://www.youtube.com/watch?v=pqc4kxMTCsc http://www.youtube.com/watch?v=pqc4kxMTCsc <3 <3 <3 <3 <3

Groxx 16y ago
This totally made my day. Many thanks :)
- tenderlove 16y ago
  I aim to please! :-D
petercooper 16y ago
Interesting to know! (UPDATE: Looks like I'm wrong ;-) See last update.) It seems this issue was raised in 2008 and a solution (of sorts) suggested: https://rspec.lighthouseapp.com/projects/5645/tickets/504-warning-free-rspec-a-solution-for-useless-use-of-in-a-void-context-warnings https://rspec.lighthouseapp.com/projects/5645/tickets/504-wa... .. David Chelimsky seemed to think Ruby 1.9 would lose this warning but it didn't and he reopened the ticket (and it's still open 2 years later) :-) The "check" workaround seems generic and viable, if noisy. But I thought I'd see what actually happens when you try a super simple example with RSpec itself: require 'rspec' describe "a number" do it "should be equal to itself" do 1.should == 1 end end Running with warnings gives some warnings in diff-cls (oops) but none for the 1.should == 1 - the mystery gets a little deeper (RSpec masking it somehow?). UPDATE: I think I found the reason after scouring RSpec 2.0's source. Based on your example but putting should in Kernel rather than Object: module Kernel def should; self; end end def omg 1.should == 1 end omg You get no warning in this case. Curiously, though, if you ditch omg and just run the 1.should == 1 direct, you still get a warning. Confusinger and confusinger. LAST UPDATE: I'm leaving the above for completeness but it appears the result is not such a useful one (see tl's response ;-))
- tenderlove 16y ago
  No, adding should to Kernel fixes nothing. Your definition of the omg method returns the result of the comparison, thus it is no longer a void context. So the return value of omg is the return value of the comparison. In your RSpec specs, if you only have one "==" expectation and it is the last one of the block, you will not get a warning. I HAVE MADE ANOTHER AWESOME VIDEO WITH SUPER AWESOME MUSIC TO ILLUSTRATE!!!! http://www.youtube.com/watch?v=M8SB7mcQfrY http://www.youtube.com/watch?v=M8SB7mcQfrY Hope this makes sense! :-D <3 <3 <3 <3 <3 <3 <3 <3
  - petercooper 16y ago
    Ah, so it does - thanks for clearing it up. I wondered why you were throwing that extra "true" in there so didn't do it on my v2 but should have pondered this more deeply ;-) I've updated my comment with the relevant notes. All that said, though, this is sucky. But since I never run with warnings on, I'm going to put some headphones on and hop around shouting "LA LA LA" whenever I run my specs next.. or I could partake in this grotesque workaround of temporarily forcing warnings off: http://codesnippets.joyent.com/posts/show/1438 http://codesnippets.joyent.com/posts/show/1438
sleight42 16y ago
I've got to buy you a beer one of these days.
dchelimsky 16y ago
RSpec 2 introduced an eq matcher so you can do this warning free: i.porkchop_sandwiches.count.should eq(1). Then for object identity you can still use be: i.porkchop_sandwiches.first.should be(my_sandwich) This is actually more in line with the original RSpec, which had should_equal and should_be, and I prefer it because you eliminate the warning, and (I think that) "1.should eq(1)" actually speaks better than "1.should == 1" for someone familiar with ruby but new to RSpec.
- petercooper 16y ago
  Fair enough, though I know what == means in Ruby and eq is additional, duplicated syntax to learn (as with assert_equals). Without hitting the docs, I wonder what the other comparisons are in this alternate DSL. I could have a good guess.. lt, gt.. not sure on less than or equal to, regex matching, etc. I'd have to look up or memorize those rather than use syntax reinforced over years of use that already does the job. How something sounds is not so important to me, AppleScript swore me off the "sounds like English" route :-) Naturally this is a matter of opinion, but it's testament to your fine work with RSpec (and particularly in the recent modularization work) that it deals deftly with differing opinions without putting anyone at a serious disadvantage.
  - dchelimsky 16y ago
    Thanks for the props. The other operators are still supported as/is and don't cause the warning that == does.

Groxx 16y ago

This totally made my day. Many thanks :)

tenderlove 16y ago
I aim to please! :-D

petercooper 16y ago

Interesting to know! (UPDATE: Looks like I'm wrong ;-) See last update.) It seems this issue was raised in 2008 and a solution (of sorts) suggested: https://rspec.lighthouseapp.com/projects/5645/tickets/504-warning-free-rspec-a-solution-for-useless-use-of-in-a-void-context-warnings https://rspec.lighthouseapp.com/projects/5645/tickets/504-wa... .. David Chelimsky seemed to think Ruby 1.9 would lose this warning but it didn't and he reopened the ticket (and it's still open 2 years later) :-) The "check" workaround seems generic and viable, if noisy. But I thought I'd see what actually happens when you try a super simple example with RSpec itself: require 'rspec' describe "a number" do it "should be equal to itself" do 1.should == 1 end end Running with warnings gives some warnings in diff-cls (oops) but none for the 1.should == 1 - the mystery gets a little deeper (RSpec masking it somehow?). UPDATE: I think I found the reason after scouring RSpec 2.0's source. Based on your example but putting should in Kernel rather than Object: module Kernel def should; self; end end def omg 1.should == 1 end omg You get no warning in this case. Curiously, though, if you ditch omg and just run the 1.should == 1 direct, you still get a warning. Confusinger and confusinger. LAST UPDATE: I'm leaving the above for completeness but it appears the result is not such a useful one (see tl's response ;-))

tenderlove 16y ago
No, adding should to Kernel fixes nothing. Your definition of the omg method returns the result of the comparison, thus it is no longer a void context. So the return value of omg is the return value of the comparison. In your RSpec specs, if you only have one "==" expectation and it is the last one of the block, you will not get a warning. I HAVE MADE ANOTHER AWESOME VIDEO WITH SUPER AWESOME MUSIC TO ILLUSTRATE!!!! http://www.youtube.com/watch?v=M8SB7mcQfrY http://www.youtube.com/watch?v=M8SB7mcQfrY Hope this makes sense! :-D <3 <3 <3 <3 <3 <3 <3 <3
- petercooper 16y ago
  Ah, so it does - thanks for clearing it up. I wondered why you were throwing that extra "true" in there so didn't do it on my v2 but should have pondered this more deeply ;-) I've updated my comment with the relevant notes. All that said, though, this is sucky. But since I never run with warnings on, I'm going to put some headphones on and hop around shouting "LA LA LA" whenever I run my specs next.. or I could partake in this grotesque workaround of temporarily forcing warnings off: http://codesnippets.joyent.com/posts/show/1438 http://codesnippets.joyent.com/posts/show/1438

sleight42 16y ago

I've got to buy you a beer one of these days.

dchelimsky 16y ago

RSpec 2 introduced an eq matcher so you can do this warning free: i.porkchop_sandwiches.count.should eq(1). Then for object identity you can still use be: i.porkchop_sandwiches.first.should be(my_sandwich) This is actually more in line with the original RSpec, which had should_equal and should_be, and I prefer it because you eliminate the warning, and (I think that) "1.should eq(1)" actually speaks better than "1.should == 1" for someone familiar with ruby but new to RSpec.

petercooper 16y ago
Fair enough, though I know what == means in Ruby and eq is additional, duplicated syntax to learn (as with assert_equals). Without hitting the docs, I wonder what the other comparisons are in this alternate DSL. I could have a good guess.. lt, gt.. not sure on less than or equal to, regex matching, etc. I'd have to look up or memorize those rather than use syntax reinforced over years of use that already does the job. How something sounds is not so important to me, AppleScript swore me off the "sounds like English" route :-) Naturally this is a matter of opinion, but it's testament to your fine work with RSpec (and particularly in the recent modularization work) that it deals deftly with differing opinions without putting anyone at a serious disadvantage.
- dchelimsky 16y ago
  Thanks for the props. The other operators are still supported as/is and don't cause the warning that == does.