Broken expectation raises undefined method `surface_descriptions_in' #473

mhenrixon opened this Issue Feb 21, 2014 · 15 comments


None yet

7 participants


Take the following spec, when all is well no problem but every time I have an error on comparing hashes I get the below error.

# specs/serializers/activity_serializer_spec.rb
require 'spec_helper'

describe ActivitySerializer do
  let(:activity) { build_stubbed(:activity, xp: 10, pp: 15, avatar: "gandalf") }
  let(:serializer) { }

  it 'serializes the right attributes' do
    expected = {
      "id"         =>,
      "xp"         => activity.xp,
      "pp"         => activity.pp,
      "type"       => activity.type.to_s.camelize(:lower),
      "avatar"     => activity.avatar,
      "data"       =>,
      "username"   => activity.username,
      "playerId"   => activity.player_id,
      "createdAt"  => activity.created_at

    pp expected
    pp serializer.as_json
    expect(serializer.as_json).to eq expected

I feel like this might be related to rspec/rspec-support#41

ActivitySerializer serializes the right attributes
     Failure/Error: expect(serializer.as_json).to eq expected
       undefined method `surface_descriptions_in' for RSpec::Matchers::Composable:Module
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/diff_presenter.rb:106:in `object_to_string'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/diff_presenter.rb:40:in `diff_as_object'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/fail_with.rb:28:in `fail_with'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/handler.rb:36:in `handle_failure'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/handler.rb:49:in `handle_matcher'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-expectations-3.0.0.beta2/lib/rspec/expectations/expectation_target.rb:29:in `to'
     # ./spec/serializers/activity_serializer_spec.rb:21:in `block (2 levels) in <top (required)>'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:124:in `instance_exec'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:124:in `block in run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:185:in `call'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:185:in `block (2 levels) in <class:Procsy>'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-rails-3.0.0.beta2/lib/rspec/rails/adapters.rb:67:in `block (2 levels) in <module:MinitestLifecycleAdapter>'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:267:in `instance_exec'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:267:in `instance_exec'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/hooks.rb:420:in `block (2 levels) in run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:185:in `call'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:185:in `block (2 levels) in <class:Procsy>'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/hooks.rb:422:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/hooks.rb:476:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:276:in `with_around_each_hooks'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example.rb:121:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example_group.rb:468:in `block in run_examples'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example_group.rb:464:in `map'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example_group.rb:464:in `run_examples'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/example_group.rb:431:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/command_line.rb:27:in `block (2 levels) in run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/command_line.rb:27:in `map'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/command_line.rb:27:in `block in run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/reporter.rb:47:in `report'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/command_line.rb:24:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/runner.rb:100:in `run'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/lib/rspec/core/runner.rb:31:in `invoke'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/gems/rspec-core-3.0.0.beta2/exe/rspec:4:in `<top (required)>'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/bin/rspec:23:in `load'
     # /Users/mhenrixon/.rvm/gems/ruby-2.1.0/bin/rspec:23:in `<main>'

Thanks for reporting this. I think I may know what's going on. Do you have YARD loaded at runtime in your project? If so, it's because of 0b55992. We can fix that pretty easily, although we'll have to find a better solution for doc'ing things properly.


Yup YARD is loaded, anything I can do to fix that for now?


Do you actually need YARD in your test environment? Or is it simply listed in your Gemfile and Bundler.require is loading it even though you're not using it in your tests?

If you're not using it in your test environment, simply stop it from being loaded to work around this bug (e.g. by adding :require => false to the entry in your Gemfile).

I hope to have an rspec-expecations fix for this ready to go later today.


I don't need it at all really but it comes with and is loaded automatically. I use pry for debugging my tests I will require only the needed gems in test mode for now.


You can try undefining the YARD constant before rspec-expectations is loaded as a temporary hack/workaround.


I have a fix ready to go in #474, if you want to git that a shot.

@myronmarston myronmarston added a commit that closed this issue Feb 21, 2014
@myronmarston myronmarston Don't change visibility based on if YARD is loaded.
Originally, I expected YARD to be loaded only when
we generate docs, but users may have YARD loaded
in their environment as well.

Fixes #473.
JonRowe commented Feb 22, 2014

@mhenrixon let us know if this is still an issue for you


@JonRowe I can confirm that I had this issue with beta2 and pulling down master fixed the issue for me.


Yup, but loading the master of rspec-expectation broke my rails application, so I'd recommend loading master from the state just after that fix (until it gets into a release version):

gem 'rspec-expectations', github: 'rspec/rspec-expectations', ref: '4f6281322f53fd3763268474193afba79369592b'


@jtomaszewski -- I'm not aware of any regressions in rspec-expectations. Can you file an issue for whatever issue you saw in your rails app? We can't fix your issue if we're not made aware of it!


Has anyone made any progress on this?


@davidimoore -- we've fixed it in master. The fix will be in the next release. You can get the fix before then by pointing your gemfile at github.

JonRowe commented Mar 26, 2014

@davidimoore this was fixed in 4f62813


Ok thanks.


thanks for fixing this!

@mhenrixon mhenrixon referenced this issue in sgonyea/sidekiq-unique-jobs May 10, 2014
@sgonyea sgonyea Make mock available by default
- The require will not trigger until redis_mock accessed.

- If we happen to call `SidekiqUniqueJobs.redis_mock.flushdb`
  in a `before(:each)` but `testing_enabled?` hasn't yet been
  called, tests will all blow up. This avoids the need for an
  extra `require` in the test/spec helper.

- Switches to ruby's built-in `defined?` operator.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment