-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Typhoeus.stub should not be converted to new rspec syntax #4
Comments
Thanks! Yeah, I'll keep Transpec up-to-date with RSpec.
The whitelist solution sounds good to me. Typhoeus seems to be famous and the name is unique enough. |
Thanks for the quick fix :). |
BTW, I noticed that |
Thanks. I'll handle it too. By the way, I'm wondering if there's a way to grep codes of all gems. |
Thanks! I'll try later. |
TODO: Support method invocation on implicit self (no receiver node). Related to #4.
Now Transpec checks whether |
👍 Sounds great! |
First off, great work on this project! If this continues to stay up-to-date with RSpec as we approach the 3.0 release (still a ways off), I plan to promote this and point users to it as an aid to upgrading.
Anyhow, I tried it for the first time tonight to upgrade VCR's specs, and ran into one issue.
Typhoeus provides an HTTP stubbing API in the form of
Typhoeus.stub(url, options)
:https://github.com/typhoeus/typhoeus/blob/6a59c62d7e8bda81ec726035b79e035aefd8b05c/lib/typhoeus.rb#L66-L85
Transpec attempted to upgrade this to RSpec's
allow(...).to receive
syntax but it was invalid because::Typhoeus.stub
isn't using rspec'sstub
at all even though it looks like it. While this isn't really a bug in transpec (how could it know?) I think it could help if transpec maintained a whitelist of known exceptions for things it should not attempt to upgrade, and::Typhoeus.stub
could be on the list. There may be others other users will report in the future.The text was updated successfully, but these errors were encountered: