How to disable / mock / stub did_you_mean from running during an rspec spec

[JDutil]

I have a spec that fails for me due to did_you_mean appending itself to an error message we're checking for. I've been trying to prevent did_you_mean from working during that particular spec, but haven't had any luck. What is the proper way to stub or prevent did_you_mean from working in rspec besides uninstalling the gem itself?

[yuki24]

I'm very curious to know what issue you are specifically seeing. There may be an opportunity to make did_you_mean better so you don't have to disable it.

Regardless, there are a couple ways to disable the did_you_mean. One way is to just uninstall it:

gem uni did_you_mean

The other one is to use the --disable-did_you_mean flag that tells Ruby to disable it:

ruby --disable-did_you_mean path/to/file.rb

# or if you can't directly call the ruby command:
RUBYOPT="--disable-did_you_mean" rails server
RUBYOPT="--disable-did_you_mean" rspec

[JDutil]

We are just matching on an exception message string, but the exception message gets the "Did you mean" text appended to it. We can just check the string starts with or matches our string, but it'd be nicer to match the exact string by disabling or mocking out did_you_mean gem during the spec execution.

I wasn't able to figure out a way to disable/stub/mock did_you_mean from appending the "did you mean" text to the exception message without entirely uninstalling did_you_mean, which is less than ideal since in general I like the library and want to use it just not for this particular test.

[yuki24]

I'm not sure if it's ideal, but you may be able to use the #original_message method that doesn't append a "did you mean?" message. Perhaps some documentation for it should be added to the README.

[yuki24]

I wonder if I should bring back the disabled flag that I removed a long time ago: ad6818c#diff-ecc46b8318af57a44bb5608ef098846f

DidYouMean.without_suggestions do
  # You don't get suggestions in this block
end

[JDutil]

That would be a nice solution. I haven't had the chance to try the #origin_message method yet as I hopped onto another issue, but that should solve my problem. It would also probably be easier to document and use across multiple purposes besides just stubbing a spec.