Enable one-liner syntax for expectation blocks

[rbuchss]

When the attribute or method being called from its is expected to raise or not raise an error the the spec doesn't read very well with expect { should }.

For example:

describe 'something' do
  subject { :foo }
  its(:upcase) { expect { should }.to_not raise_error }
  its(:chomp) { expect { should }.to raise_error(NoMethodError) }
end

Using is_expected_in_block instead seems to make a little more sense here:

describe 'something' do
  subject { :foo }
  its(:upcase) { is_expected_in_block.to_not raise_error }
  its(:chomp) { is_expected_in_block.to raise_error(NoMethodError) }
end

[JonRowe]

expect { should } was not er... expected to work :joy:

This is gem was intended to allow "older" spec suites to continue working when we released RSpec 3, its not really under continuing development.

That said I think I'm open to including this but is_expected_in_block is a weird name, we need it to read "right", the whole point of this syntax was to read well. Something like this might work:

its(:chomp) { will raise_error(NoMethodError) }

But you'd need to call to internally and also ensure the matchers support block expectations.

[rbuchss]

I would argue that expect { should } was 'expected' to work given this test 😉 https://github.com/rspec/rspec-its/blob/v1.2.0/spec/rspec/its_spec.rb#L91-L99

All jokes aside... Good suggestion on the naming change. I've converted it to will and will_not and should work like this:

describe 'something' do
  subject { :foo }
  its(:upcase) { will_not raise_error }
  its(:chomp) { will raise_error(NoMethodError) }
end

I've also included the relevant tests to cover block expectations

[rbuchss]

@JonRowe, I think I've addressed all your feedback on this PR. Do you have any objections to merging this or other feedback?

[JonRowe]

Thanks!