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?
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.
I'm currently upgrading my rails application from rails 4 to rails 5. Is it necessary to change from Factory_girl to Factory_bot? What will happen if I proceed with a deprecation warning? further, I might be upgrading that application to rails 6, so would factory_girl work for rails 6?
FactoryGirl was renamed to FactoryBot in October 2017. (The original name was based on some inside joke/pop culture reference, which some argued was a poor decision.)
This has got nothing to do with upgrading rails, and everything to do with upgrading factory_girl/factory_bot.
Use the new name. It makes no sense to keep the old name - and regardless, your code will break at some point when updating versions, if you don't perform the rename.
The change is quite straightforward, and there are various guides people have written about the upgrade, such as this.
Essentially, all you need to do is:
Rename factory_girl and/or factory_girl_rails in the Gemfile, to factory_bot and factory_bot_rails.
Rename any mention of FactoryGirl to FactoryBot. (You could use git grep to ensure nothing is missed.)
I'm writing an application in Rails 5 and using Rspec for tests. I'm having a lot of trouble with require 'some_model' or require 'some_controller' in my spec files. Every time I run a spec, it acts lost and doesn't seem to understand that it's in a Rails app. The suggestions I've seen range from
config.autolad_paths += %W( #{config.root}/app )
to
$LOAD_PATH << '~/my_app/app/models' which sort of works, except that my tests throw an unitialized constant for ApplicationRecord
So for all the digging around I've done, I still haven't found a good way require my MVC files while keeping my specs and spec_helper clean. There doesn't seem to be any defacto way to do so, so how do you all suggest doing it?
can you not take on the entire stress of RSpec configuration. Use the rspec-rails gem and look through the documentation to use it within your app. I guess you can get a base config with rails generate rspec:install after including the gem in your project.
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.
I got a strange problem with minitest and capybara.
I am using rails 3.2.8 and test with minitest/capybara/poltergeist. Until now every went fine. I always could test my javascript stuff.
For a new project I downloaded rails 4 to get into it a little bit. And since minitest will be the testing framework I thought it would be easy. It was not. Truth be told, I am not a hero when it comes to setting up all the stuff. I just follow Ryan Bates. After a lot of adding and removing and updating a lot of gems I decided it wasn't worth to continue to use Rails 4. I had so many issues with getting into the groove with my integration tests. All the stuff I knew did not work as expected. The axe fell when almost everything worked until I wanted to test a javascript thing. I got this error:
.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/minitest-4.6.1/lib/minitest/spec.rb:190:in `it': wrong number of arguments (2 for 1) (ArgumentError)
because of this
describe "blabla" do
it "does not do what i want it to do", js: true do
pending
end
end
It will not accept the js: true argument. Funny thing is that the describe block will accept the js: true argument.
When I went back to Rails 3.2.8, because I thought it was a Rails 4 thing, this baby followed me right into a new testsuite. I tried hard to find an answer on Google but I can't find any. My other rails 3.2.8 projects still test fine, no complains about the javascript argument. But with the new apps: no javascript testing.
I am at a loss here. I have no idea where this is coming from. Since my other 3.2.8 apps still work fine, it has probably something to do with renewed gem versions? Has anybody seen this error message? I checked the complaining minitest/spec.rb file from the error message, line 190 for several minitest versions and nothing changed in the it-method.
Please let me know if you want to see stuff (Gemfile? test_helper.rb?) if you have any clue about what might be wrong. Thanks in advance!
Casper
Minitest's spec DSL does not accept a second parameter for the it blocks. The minitest-metadata gem adds support for the second argument, and the example shows how to configure Capybara to use it. Perhaps your existing projects use minitest-metadata and configure Capybara with it, and your new projects don't?