While one could certainly use the shoulda-matchers with the new expect syntax as follows:
it 'should validate presence of :email' do
expect(subject).to validate_presence_of :email
end
or the more concise but less readable:
it { expect(subject).to validate_presence_of :email }
the one-liner should format these matchers are typically used with is explicitly supported in 2.14 even when config.syntax == :expect. When should is being used with an implicit subject as in:
describe User
it { should validate_presence_of :email }
end
it does not rely on the monkey patching of Kernel that should otherwise depends on.
It doesn't appear that shoulda_matchers does this, but it's easy enough to write it yourself::
context "if eligible" do
before { allow(subject).to receive(:eligible?).and_return(true) }
it { should validate_presence_of(:name) }
end
context "if ineligible" do
before { allow(subject).to receive(:eligible?).and_return(false) }
it { should_not validate_presence_of(:name) }
end
Best Answer
While one could certainly use the shoulda-matchers with the new expect syntax as follows:
or the more concise but less readable:
the one-liner
shouldformat these matchers are typically used with is explicitly supported in 2.14 even whenconfig.syntax == :expect. Whenshouldis being used with an implicit subject as in:it does not rely on the monkey patching of
Kernelthatshouldotherwise depends on.This is covered in https://github.com/rspec/rspec-expectations/blob/master/Should.md. In fact, that documentation even uses the above
shouldamatcher example to illustrate this exception.See also Using implicit `subject` with `expect` in RSpec-2.11, which discusses a configuration option which lets you use as an alternative to
it.Update: As of RSpec 3.0 (beta2), you will also be able to use: