Skip to content
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

Deprecate expect { }.not_to raise_error(SpecificErrorClass) #244

Conversation

fables-tales
Copy link
Member

Related #231.

Deprecates raising with a specific error class and adds specs for this. Also a spec to ensure that the deprecation does not affect using this with a specific error class.

Sam Phippen added 2 commits April 21, 2013 17:41
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
@@ -14,6 +14,10 @@ def initialize(expected_error_or_message=Exception, expected_message=nil, &block
end

def matches?(given_proc, negative_expectation = false)
if negative_expectation == :negative_expectation && @expected_error != Exception
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just check if negative_expectation -- no need to compare it to the symbol. At the call site it passes the symbol because that's more expressive than passing true (which doesn't mean a whole lot on its own).

Also, what do you think about extracting the @expected_error != Exception part into a method that expresses it better? Maybe something like expecting_specific_exception?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what do you think about extracting the @expected_error != Exception part into a
method that expresses it better? Maybe something like expecting_specific_exception?

👍

@fables-tales
Copy link
Member Author

Myron these are all great catches as usual. I'm currently facing the last 3 weeks of writing my master's thesis so expect very intermittent stuff from me.

Sam Phippen added 2 commits April 25, 2013 00:16
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
includes breaking out an "expecting_specific_exception?" query.

Signed-off-by: Sam Phippen <samphippen@googlemail.com>
@@ -14,6 +14,13 @@ def initialize(expected_error_or_message=Exception, expected_message=nil, &block
end

def matches?(given_proc, negative_expectation = false)
if negative_expectation && expecting_specific_exception?
p "warning deprecation"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extraneous puts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup! This is now gone.

Sam Phippen added 4 commits April 25, 2013 00:29
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
Signed-off-by: Sam Phippen <samphippen@googlemail.com>
@JonRowe
Copy link
Member

JonRowe commented Apr 24, 2013

Looks good to me, merge away

@fables-tales
Copy link
Member Author

Cool.

fables-tales pushed a commit that referenced this pull request Apr 24, 2013
…error-class

Deprecate `expect { }.not_to raise_error(SpecificErrorClass)`
@fables-tales fables-tales merged commit ddb0b7c into rspec:master Apr 24, 2013
@fables-tales fables-tales deleted the deprecate-not-raise-specific-error-class branch April 27, 2013 21:24
@dchelimsky
Copy link
Contributor

I'm updating the spec for this and noticed that expect { .. }.not_to raise_error(message) is still supported. I think we should deprecate that as well based on the same motivation described in #231. WDYT?

@fables-tales
Copy link
Member Author

@dchelimsky 👍

@myronmarston
Copy link
Member

Great idea.

On Thu, May 16, 2013 at 10:26 AM, Sam Phippen notifications@github.comwrote:

@dchelimsky https://github.com/dchelimsky [image: 👍]


Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18015854
.

@dchelimsky
Copy link
Contributor

Building now on a separate branch: https://github.com/rspec/rspec-expectations/compare/deprecate-not-to-raise-error-with-message

There are some other issues addressed on that branch, but unless there is objection I'm just going to merge the branch once travis says it's OK to do so.

@dchelimsky
Copy link
Contributor

Travis failed the build due to a failing cuke, but the same cuke is failing on master - looking into it.

@myronmarston
Copy link
Member

Two things (I can't figure out how to comment on that view, sadly):

  • Nice to see usage of the new syntax :).
  • I noticed the deprecation warning is expect { }.not_to raise_error(SpecificErrorClass) for both the raise_error(SomeClass) and
    raise_error("Some message") case. That's potentially confusing. Maybe
    it should just be raise_error(something) or separate messages for these
    two cases?

Thanks for taking care of this!

On Thu, May 16, 2013 at 10:50 AM, David Chelimsky
notifications@github.comwrote:

Building now on a separate branch:
https://github.com/rspec/rspec-expectations/compare/deprecate-not-to-raise-error-with-message

There are some other issues addressed on that branch, but unless there is
objection I'm just going to merge the branch once travis says it's OK to do
so.


Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18017414
.

@dchelimsky
Copy link
Contributor

I'll clarify the failure message. Thx.

@dchelimsky
Copy link
Contributor

The current travis failure is due to this:

  1) using the expect syntax
     Failure/Error: specify { expect(3).to eq(3) }
       only the `receive` matcher is supported with `expect(...).to`, but you have provided: #<RSpec::Matchers::BuiltIn::Eq:0x007fb5792e5758>
     # ./syntaxes_spec.rb:9:in `block (2 levels) in <top (required)>'

This suggests that the new message expectation syntax is spec'd to disallow any matcher besides receive to expect(obj).to, which breaks on expect(obj).to eq, but there is only one failing cuke at the moment (I'd expect a lot more failures). I'll follow up in a bit as I learn, but if any of you have any insights on this, out with them, please!

@myronmarston
Copy link
Member

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in rspec-mocks but disabled in rspec-expectations (or if you're using rspec-mocks standalone w/o rspec-expectations). Sounds like there's a bug somewhere in that logic...

@dchelimsky
Copy link
Contributor

I added this to the cuke and it passed:

  •    config.mock_with :rspec do |c|
    
  •      c.syntax = :should
    
  •    end
    

Make sense to you, @myronmarston?

On Thu, May 16, 2013 at 1:16 PM, Myron Marston notifications@github.comwrote:

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in
rspec-mocks but disabled in rspec-expectations (or if you're using
rspec-mocks standalone w/o rspec-expectations). Sounds like there's a bug
somewhere in that logic...


Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18019083
.

@myronmarston
Copy link
Member

Yep, thanks for fixing that!

On Thu, May 16, 2013 at 11:19 AM, David Chelimsky
notifications@github.comwrote:

I added this to the cuke and it passed:

  • config.mock_with :rspec do |c|
  • c.syntax = :should
  • end

Make sense to you, @myronmarston?

On Thu, May 16, 2013 at 1:16 PM, Myron Marston notifications@github.comwrote:

I know a bit about that. It's generated here:

https://github.com/rspec/rspec-mocks/blob/master/lib/rspec/mocks/targets.rb#L11-L21

That error should only be raised if the :expect syntax is enabled in
rspec-mocks but disabled in rspec-expectations (or if you're using
rspec-mocks standalone w/o rspec-expectations). Sounds like there's a
bug
somewhere in that logic...


Reply to this email directly or view it on GitHub<
https://github.com/rspec/rspec-expectations/pull/244#issuecomment-18019083>

.


Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18019299
.

@dchelimsky
Copy link
Contributor

@myronmarston b956215

WDYT?

@myronmarston
Copy link
Member

Looks great!

On Thu, May 16, 2013 at 12:03 PM, David Chelimsky
notifications@github.comwrote:

@myronmarston https://github.com/myronmarston b956215b956215a0d12

WDYT?


Reply to this email directly or view it on GitHubhttps://github.com//pull/244#issuecomment-18022090
.

@sethvargo
Copy link

@myronmarston how does one assert that a function raises a certain type of error then? Especially when working on a CLI application, just checking that something raises an error is not enough - I need to check if the error is actually X, not Y. Is there a replacement to this method then?

@cupakromer
Copy link
Member

@sethvargo You can still do that:

expect{}.to raise_error(ArgumentError)

What is being deprecated is the negation:

expect{}.not_to raise_error(ArgumentError)

to vs not_to/to_not. The reason is the negative version is brittle. You could raise all kinds of errors that no longer meet the matcher after a code change, but the test will still pass (false positive). Instead for the negative version you should just expect nothing is raised.

@sethvargo
Copy link

Ahh okay. That's a bit confusing. Thanks!

schierlm pushed a commit to schierlm/metasploit-framework that referenced this pull request Nov 3, 2013
Checking that a specifc error is not raised is deprecated in rspec:
rspec/rspec-expectations#244
abaird pushed a commit to convio/watirmark that referenced this pull request Nov 15, 2013
according to: rspec/rspec-expectations#244, expecting a specific error to not be raised is deprecated and not really a good idea.  Indeed, I found two other testcases where a different error was being raised other than the one we specified.  I will fix those in later commits.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants