'not defined constant' errors when using instance_double

[floydj]

I have the following:

let(:project) { instance_double 'Project' }

But when I run specs that access this double, I get Project is not a defined constant. Perhaps you misspelt it?

I have the following in my spec_helper.rb file:

config.mock_with :rspec do |mocks|
  mocks.verify_doubled_constant_names = true
end

I have a Project class with:

class Project < ActiveRecord::Base

What am I missing here?

[myronmarston]

At the time your spec runs, Project is not a defined constant. Are you loading it anywhere (e.g. with require 'project' or similar)?

If you are relying upon rails autoloading, you can change instance_double 'Project' to instance_double Project (it works fine to pass the class itself rather than the string) -- referencing the constant will cause rails to load the model.

In general, if you always want your verifying doubles to verify and are willing to pay the cost of loading the classes, passing the class as a constant reference works simpler/better than using the string form and verify_doubled_constant_names = true. OTOH, using the string form provides a way to write an isolated spec that doesn't require the named class to be loaded but will verify when it is loaded. When doing that, I tend to set verify_doubled_constant_names = true in a config file that is only loaded when all specs are run (and all implementation files are loaded). For individual spec files, using verify_doubled_constant_names = true kinda destroys the whole point of passing the class name as a string, as it prevents you from being able to run the spec w/o the class loaded, which is the entire point of supporting the string form in the first place.

Closing, but let me know if that doesn't make sense and we can reopen.

[floydj]

@myronmarston - Thanks for the explanation.

But when I use this:

let(:project) { instance_double(Project, metric?: false) }

I now get Project does not implement: metric?, even though Project does have metric as a boolean field.

[floydj]

@myronmarston - please disregard. I figured it out. Thanks again.

[mockdeep]

@myronmarston would it make sense for RSpec to anticipate autoloading and try to resolve it? It seems like it could be something like:

begin
  const_get(class_name)
rescue NameError
  # show error message
end

[JonRowe]

@mockdeep not really because that behaviour isn't prevalent outside of Rails, it's much more common to have to require the things you expect to use. If you're using rspec in rails environment using the constant directly is a much better way to force the desired behaviour.

[mockdeep]

@JonRowe I guess that makes sense, though it seems like it would make the implementation a little more flexible for these kinds of use cases (as well as less confusing). I'll use the constant for now.

[myronmarston]

@mockdeep - if you are wanting/expecting the class to be loaded, why use the string form at all? The entire reason the string form exists is for situations where the user doesn't want the class loaded, so adding logic to it to load the const goes against its entire purpose.

[mockdeep]

@myronmarston So I can think of two arguments in favor of a more flexible implementation. The first is surprise. Various examples on the internet (including Avdi's video) use the string syntax, so when someone tries to emulate that and it doesn't work for them, they're going to have to google around to figure out what happened, or they'll open an issue on RSpec, or maybe they'll just give up. There's this subtle caveat that if you're in Rails or another auto-loaded environment, you have to use this other syntax in order to get it to work.

The other point is that one might want to be able to toggle the verification on and off. I could see a use case that while you're driving something out you aren't necessarily going to be worried that the interfaces are spot on, so you would be inclined to use the string syntax, but once the individual components are in place you could toggle on the verification. Right now it sort of pushes a "depth first" approach to testing in a Rails environment, as you have to define each of the classes you're mocking out down the tree. I personally don't mind, but I could see it being a little frustrating at times.

[JonRowe]

You forget that Rails is causing the surprising case here, and even then only without eager_loading turned on, in normal Ruby the string usage behaves as expected, you'd have to require the class before use.

[mockdeep]

That's true, I'm not blaming RSpec for the confusion necessarily, but it's there. @myronmarston explained it in the comments for the video, but eager_loading doesn't really make much sense either, since you might only want to run an individual spec, which shouldn't load all of the classes in the app.

[JonRowe]

Rails autoloading has more confusing behaviour than just this. If you expect something to be present you should load the entire of app or specify the bits you do want.

[mockdeep]

How so? I haven't run into problems with it in my tests, aside from making sure all of my folders are included in the autoload paths. I've never had to manually require individual files for it.

[JonRowe]

It has some quirks regarding name spaced constants and the like

[myronmarston]

The first is surprise. Various examples on the internet (including Avdi's video) use the string syntax, so when someone tries to emulate that and it doesn't work for them, they're going to have to google around to figure out what happened, or they'll open an issue on RSpec, or maybe they'll just give up.

I'm thinking we should update our docs to show the non-string form and explain when you'd want to use one vs the other.

There's this subtle caveat that if you're in Rails or another auto-loaded environment, you have to use this other syntax in order to get it to work.

What? I admittedly haven't done a real rails project since the rails 2 days, but I find this surprising. I believe @xaviershay (the designer of verifying doubles) tends to use the string form in rails projects without any issues. What makes you say you have to use the non-string syntax to get it to work? Is it just that RSpec doesn't load the constant for you? (if so, that's it working as designed).

The other point is that one might want to be able to toggle the verification on and off. I could see a use case that while you're driving something out you aren't necessarily going to be worried that the interfaces are spot on, so you would be inclined to use the string syntax, but once the individual components are in place you could toggle on the verification.

This is what the string form is meant to provide -- you can use the double before the interface is defined, and later, once it is defined, when your test that uses the verified double runs with the class definition loaded, the verification will be enabled.