Example of using an anonymous class to build an RSpec custom Matcher

gistfile1.rb

def be_guest_member_of(expected)
  Class.new do
    def initialize(expected)
      @expected = expected
    end

    def matches?(target)
      @target = target
      @target.memberships.where(role: "guest").map(&:network).include? @expected
    end

    def failure_message_for_should
      "expected #{@target.inspect} to be a guest member of #{@expected.inspect}"
    end

    def failure_message_for_should_not
      "expected #{@target.inspect} to not be a guest member of #{@expected.inspect}"
    end
  end.new(expected)
end

# usage example
user1.should be_guest_member_of network2
user1.should_not be_guest_member_of network1

too slow :P

My User class doesn't have a #guest_member_of?(network) method so I can't use automatic predicate matchers. Interestingly, it seems that needing this method in my spec might presage needing it in my application code sometime soon. But I'm tdd'ing and didn't want to add a method to the app code that was only needed by the spec.

@sobrinho what do you mean?

@obie every time you use the matcher, a new class is created and after that is instantiated.

You may want to do that:

module Matchers
  extend RSpec::Matchers::DSL

  matcher :have_disabled_field do |field|
    match do |page|
      page.find_field(field)[:disabled].should eq 'true'
    end

    failure_message_for_should do |page|
      "expected #{page.text.inspect} to have disabled field #{field.inspect}"
    end

    failure_message_for_should_not do |page|
      "expected #{page.text.inspect} not to have disabled field #{field.inspect}"
    end
  end

  matcher :have_disabled_button do |field|
    match do |page|
      page.find_button(field)[:disabled].should eq 'true'
    end

    failure_message_for_should do |page|
      "expected #{page.text.inspect} to have disabled button #{field.inspect}"
    end

    failure_message_for_should_not do |page|
      "expected #{page.text.inspect} not to have disabled button #{field.inspect}"
    end
  end

  matcher :have_notice do |notice|
    match do |page|
      page.should have_css(".notice", :text => notice)
    end

    failure_message_for_should do |page|
      "expected #{page.text.inspect} to have notice #{notice.inspect}"
    end

    failure_message_for_should_not do |page|
      "expected #{page.text.inspect} not to have notice #{notice.inspect}"
    end
  end

  matcher :have_alert do |alert|
    match do |page|
      page.should have_css(".alert", :text => alert)
    end

    failure_message_for_should do |page|
      "expected #{page.text.inspect} to have alert #{alert.inspect}"
    end

    failure_message_for_should_not do |page|
      "expected #{page.text.inspect} not to have alert #{alert.inspect}"
    end
  end
end

RSpec.configure do |config|
  config.include Matchers, :type => :request
end

I didn't make a benchmark but is obviously that creating a new class every time you use the matcher will be slow :)

@supaspoida, methinks the more appropriate question here would be as to what is the specific benefit of that class being anonymous?

@dexterous No benefit, in fact probably harmful given the matcher DSL example provided by @sobrinho :)

@obie yeah; in fact, given that the class isn't built dynamically using the parameter to be_guest_member_of, simply pulling the class out of the function and naming it might boost, not just performance, but also clarity of intent by at least an order of magnitude.

RSpec::Matchers also has a .define that will take care of the config stuff for you. Throw it in spec/support like so:

RSpec::Matchers.define :be_guest_member_of do |expected|
  match do |target|
    target.memberships.where(role: "guest").map(&:network).include? expected
  end

  failure_message_for_should do |target|
    "expected #{target.inspect} to be a guest member of #{expected.inspect}"
  end

  failure_message_for_should_not do |target|
    "expected #{target.inspect} to not be a guest member of #{expected.inspect}"
  end
end

I would argue that this is the cleanest way to go, but make no claims regarding performance.

I do think in this case that reaching through so many associations like that is an indicator that the design should change to improve the tests though.