I'm just trying to run some tests, and I get this error:
undefined method `feature' for Reform::Form:Class (NoMethodError)
It happens in /usr/local/bundle/gems/reform-2.2.3/lib/reform/form.rb:75,
that line in form.rb is the first time the DSL word feature is used.
Of course this does not happen when I run my rails app but only when I run rspec..
It is defined in the Disposable gem used by reform. At first I thought that the problem is with an older version of rspec but even after I updated to the latest versions, things are still broken. Reading the code or documentation did not lead me to any specific behavior of loading that is different between tests and application runs.
The versions of gems I use are:
rspec-3.3.0, reform-2.2.3, disposable-0.3.2
Does anyone have a clue?
-- Update --
After removing the entire test framework (removing RSpec and deleting all related files) and installing again I got to the point that RSpec is running by itself but when trying to load my environment in the test file it fails on the same error.
Well, the problem was that we added an override of Reform's Contract and did not do it too gracefully, thus not requiring all the things the original Reform Contract required. As a fix we now created a base
Contract that inherits from Reform::Contract instead of overriding it and now all works well. The only reason we found it when running RSpec and not in running Rails c is because of different loading order of things.
Related
I maintain https://rubygems.org/gems/scimitar. Yesterday, we wanted to upgrade our primary application to Rails 7. This required a corresponding upgrade of Scimitar.
Tests I think are quite straightforward for a Rails engine; you have a dummy Rails app inside your tests, which requires the gem code as usual (require 'scimitar' in application.rb, in this case) and then - well - I guess via the mount in the dummy app's routes.rb, or some other autoloading magic, it thereafter "just works". Classes that are defined in the engine's application components (e.g. /app/models/gemname/foo.rb -> Gemmname::Foo) are autoloaded and available in your dummy application (e.g. /spec/dummy/app/controllers/some_controller.rb can reference Gemname::Foo).
The test suite works fine in Rails 6. If I change the gemspec file to reference Rails 7 and bundle update, tests immediately all fail. None of the constants defined in the engine are visible to the dummy app and since they're referenced by a configuration file in spec/dummy/app/config/initializers/scimitar.rb, the dummy app can't even complete Ruby parsing without raising NameError (uninitialized constant). I also ran a Rails 7 upgrade on that dummy app, but it does kinda nothing and had almost no changes; there were no changes to observed behaviour (tests still failed) and the post-upgrade dummy app ran tests successfully with the gem on Rails 6.
So, it just fails to behave in a recognisably sensible way on Rails 7.
Ruby version is unchanged at 2.7.x (though I would have bump to 3.1 if the Rails 7 update had worked).
I cannot find anything about this in 6->7 upgrade docs; classic autoloader has never been used and there is no specification about it either way; config.load_defaults as 6.0 or 7.0 makes no difference at all; I tried creating a new engine plugin under Rails 7 to play spot-the-difference, but couldn't see what might be wrong and it was obfuscated somewhat since I'm using RSpec but the out-of-box template uses Minitest.
Can anyone please help explain what is going on here?
As it stands in Rails 7.0.1, I found no solution so had to hack around it. Anyone using the Scimitar gem would need to wrap their initializer code (config/initializers/scimitar.rb) with:
Rails.application.config.to_prepare do
...
end
https://api.rubyonrails.org/classes/ActiveSupport/Reloader.html#method-c-to_prepare
Doing this inside the Gem's own engine initializer code and the dummy app initializer code allowed the test suite to run. Likewise, there were quite a few places in our main Rails application beyond just Scimitar that suddenly required this workaround, including some examples of just plain old Ruby gems.
Not sure if I could reliably reproduce this, but sometimes when I switch branches in development all requests start throwing an undefined method error inside of a helper. The method is present on both branches. I am using global helpers (helper :all).
To fix the issue, I go into the helper file and save any change. Usually I just add a new line to the end of it. After saving, it works fine. Seems like a caching issue.
Has anyone else seen this and resolved it? I am on Rails 4.2.1. As far as I know this only happens in development mode.
Since you are using Rails 4.2, spring has probably cached the code from the old branch. After switching to the new branch remember to run:
spring stop
Spring will restart itself the next time you run the server, tests, or other Rails commands.
I've recently got into RSpec and i'm writing some tests for my code, one of things my code has is a section where it starts by going if category.name.includes?(matcher) and then it does something, running this code in production is fine however whenever i'm testing that piece of code with RSpec I get the following error:
undefined method 'includes?' for "category21":String
To clear some things up, my factories do clearly define the categories name, i'm mainly wondering if I need to include some form of library to get it to play nicely?
Thanks, Grant
You should use include?, not includes?.
I've tested this by running rails c both before and after git stash. On Rails 4.1 in Mavericks, after following the instructions to add the versions table and adding has_paper_trail to three models, whenever I run rails c I get
irb: warn: can't alias context from irb_context.
I've spent some time Googling without much luck, there's old threads talking about rspec, but I don't see how that's relevant since I'm not using it. Any ideas why this is happening?
RSpec used to polute provide Object top-level methods, e.g. describe, context, etc. Fortunately they've got rid of all the monkey patching in version 3, and now all these methods are namespaced under RSpec.
One can change this behaviour through the expose_dsl_globally config flag. For backwards compatibility, it defaults to true.
The warning shows up when you open the console because paper_trail automatically loads its rspec helpers when rspec is found. And it calls RSpec.configure before you have the chance to tweak your own configuration.
One possible solution would be paper_trail to disable the automatically loading and let users to load it themselves when they see fit. However, I am not aware of the internals of the library, so I can't guarantee this wouldn't break other things.
Best!
This is now fixed in papertrail 4.0.0, here's the commit.
We are writing a Rails application that is using CouchDB as its data store. We're BDD/TDD'ing with RSpec and Cucumber, which is using WebRat for webpage testing
I'm trying to remove ActiveRecord as one of the resources that is being loaded by rails but its causing the cucumber tests to fail. I've removed all references that I can find (fixtures, environment files, etc...) but it still fails without it.
Has anyone seen this? The application runs fine without, but the test don't.
edit
I did remove the framework in env file, I also removed all the transactional fixture code. We're using the latest version of rspec and rspec-rails.
First stab at the problem.
Really I need a little more information, but...
Assuming you have done this in config/environment.rb:
# Skip frameworks you're not going to use. To use Rails without a database
# you must remove the Active Record framework.
config.frameworks -= [ :active_record ]
and are using rspec-rails 1.2.6, you would be getting an error like uninitialized constant Spec::Matchers::Change::ActiveRecord
which was brought up in ticket #810. It was fixed for 1.2.7, which was released only two weeks ago.
If that turns out not to be your problem, could you post the errors you've been getting and maybe some more information about your test environment?