When `should` is called with no explicit receiver, the call is delegated to the object returned by `subject`. Combined with an implicit subject this supports very concise expressions.
@example
describe Person do it { should be_eligible_to_vote } end
@see subject
# File lib/rspec/core/memoized_helpers.rb, line 56 def should(matcher=nil, message=nil) RSpec::Expectations::PositiveExpectationHandler.handle_matcher(subject, matcher, message) end
Just like `should`, `should_not` delegates to the subject (implicit or explicit) of the example group.
@example
describe Person do it { should_not be_eligible_to_vote } end
@see subject
# File lib/rspec/core/memoized_helpers.rb, line 70 def should_not(matcher=nil, message=nil) RSpec::Expectations::NegativeExpectationHandler.handle_matcher(subject, matcher, message) end
@note `subject` was contributed by Joe Ferris to support the one-liner
syntax embraced by shoulda matchers: describe Widget do it { should validate_presence_of(:name) } end While the examples below demonstrate how to use `subject` explicitly in examples, we recommend that you define a method with an intention revealing name instead.
@example
# explicit declaration of subject describe Person do subject { Person.new(:birthdate => 19.years.ago) } it "should be eligible to vote" do subject.should be_eligible_to_vote # ^ ^ explicit reference to subject not recommended end end # implicit subject => { Person.new } describe Person do it "should be eligible to vote" do subject.should be_eligible_to_vote # ^ ^ explicit reference to subject not recommended end end # one-liner syntax - should is invoked on subject describe Person do it { should be_eligible_to_vote } end
@see should
# File lib/rspec/core/memoized_helpers.rb, line 40 def subject raise NotImplementedError, 'This definition is here for documentation purposes only' ' - it is overriden anyway below when this module gets included.' end
Generated with the Darkfish Rdoc Generator 2.