In response to https://twitter.com/konstantinhaase/status/558308931781795840

output

Using `an_error_other_than` as an argument to `raise_error`
  failing (FAILED - 1)
  passing

Failures:

  1) Using `an_error_other_than` as an argument to `raise_error` failing
     Failure/Error: expect {
       expected an error other than SyntaxError, got #<SyntaxError: SyntaxError> with backtrace:
         # ./spec/raise_error_spec.rb:12:in `block (3 levels) in <top (required)>'
         # ./spec/raise_error_spec.rb:11:in `block (2 levels) in <top (required)>'
     # ./spec/raise_error_spec.rb:11:in `block (2 levels) in <top (required)>'

Finished in 0.00248 seconds (files took 0.11564 seconds to load)
2 examples, 1 failure

Failed examples:

rspec ./spec/raise_error_spec.rb:10 # Using `an_error_other_than` as an argument to `raise_error` failing

raise_error_spec.rb

RSpec::Matchers.define_negated_matcher :an_error_other_than, :an_instance_of

RSpec.describe "Using `an_error_other_than` as an argument to `raise_error`" do
  example "passing" do
    expect {
      raise ArgumentError
    }.to raise_error(an_error_other_than(SyntaxError))
  end

  example "failing" do
    expect {
      raise SyntaxError
    }.to raise_error(an_error_other_than(SyntaxError))
  end
end

This works fine, and IMO is more explicit about what it's doing than the form before. Bear in mind that this is still prone to producing false positives: given that it passes if the block raises any other error, a refactoring could cause it to get a NoMethodError (if you changed the method called from the block) or an ArgumentError (if you changed the method signature of the method called from the block), which would cause the example to abort before it gets to the code you are trying to test, but pass.

Is there a reason you can't write an expectation about what will happen (e.g. that a specific error is raised) rather than what won't happen?

Is there a reason you can't write an expectation about what will happen (e.g. that a specific error is raised) rather than what won't happen?

Yes, it's raising a GH::Error but should not raise a GH::TokenInvalid, which is a subclass of GH::Error so just checking for that wouldn't really work.