Join GitHub today
obj.should != something doesn't work properly #33
A coworker of mine who has never used RSpec but is interested in it pointed me to this code snippet from zenspider:
describe Integer do it "sucks" do 10.should == 10 10.should != 10 end end
This spec passes. I know that the recommended RSpec way is to use
I was going to go fix it, but this is such a simple case that I'm surprised it hasn't been addressed before, and it made me wonder if there's a specific reason it's not supported. If we're only going to support
Of course it's been addressed before, and it is not quite as simple as you might think. In Ruby 1.8 and lower,
10.should == 10 #becomes 10.should.==(10)
... whereas ...
10.should != 10 #becomes !(10.should.==(10))
So RSpec has no way to know that it's wrapped in a negating expression without parsing the file, which is not cheap. And we'd have to do it for every
If you can figure out a way to support
My intuition that this wasn't as simple as appears at first glance was correct :).
I agree 100% with not adding features to RSpec that are only supported on ruby 1.9. But I do think it's unfortunate that it's so easy to write
I'm going to play with this for a bit to see if I can come up with a way to support this on 1.8 (it's a nice challenge!), but, in the meantime, I want to discuss a plan B:
Why don't you take some time to try and solve for 1.8 first. I wouldn't want to add the warning in 1.9 one release and then take it back the next release w/ a solution :)
One possibility would be to add an optional extension that only loads if configured to add support for
So...I've researched this for a couple of hours, and this is extremely non-trivial. It looks doable using ParseTree (or maybe ruby_parser for jRuby support) but it'll be a lot of hard-to-maintain code to get it to work for all cases. For example, someone could do this:
describe MyClass do def the_matcher foo.should end it "is valid but non-standard RSpec code" do the_matcher != 17 end end
Suddenly, reading and parsing the source where the expectation was set becomes much, much harder (not that anyone should write their spec this way...). If we're going to support this, we need to support it consistently. Inconsistent feature support is confusing and unhelpful. I don't think the payoff for this feature is worth the hours of work and maintenance headaches the supporting code will bring.
I really think we're better off giving users appropriate warnings/errors. On 1.9 this is fairly easy since
On a side note, it'd be nice if github would allow me to attach this to this issue to turn it into a pull request (since pull requests create an issue...)