Recently, I've started diving into Ruby MVCs, in order to find the best, fastest, most minimal framework to build my app. Being unsatisfied with Rails, I decided to try out Padrino. I'm also trying out Outside-in TDD for a full app for the first time, so being able to write tests for all components is critical. Unfortunately, I cannot get past making models in Padrino, so I'm wondering if it's just a cause of beta software, or just error on my part.
I start off by creating my project with Cucumber and RSpec for testing and Sequel for my ORM.
$ padrino g project test -d sequel -t cucumber -c sass -b
Next, I create some model and migration:
$ padrino g model user
# ./db/migrate/001_create_users.rb
Sequel.migration do
change do
create_table :users do
primary_key :id
String :name
String :password
end
end
end
Next, of course, comes the spec. For sake of example, just something simple:
# ./spec/models/user_spec.rb
require 'spec_helper'
describe User do
it 'can be created' do
user = User.create
end
end
Now, migrate and run the spec:
$ padrino rake sq:migrate:up
$ rspec spec
F
Failures:
1) User can be created
Failure/Error: user = User.create
Sequel::DatabaseError:
SQLite3::SQLException: no such table: users
# ./spec/models/user_spec.rb:5:in `block (2 levels) in <top (required)>'
Finished in 0.00169 seconds
1 example, 1 failure
Failed examples:
rspec ./spec/models/user_spec.rb:4 # User can be created
This is very confusing. It was at this point that I thought going into the Padrino console would help me solve this strange issue. I was wrong.
$ padrino c
> User.create
=> #<User #values={:id=>1, :name=>nil, :password=>nil}>
> User.all
=> [#<User #values={:id=>1, :name=>nil, :password=>nil}>]
Fair enough results, but then I try it with the test environment:
$ padrino c -e test
> User.create
Sequel::DatabaseError: SQLite3::SQLException: no such table: users
I know that in RoR, to get integrated models to run, you have to do something like rake db:test:prepare, but doing padrino rake -T doesn't seem to reveal any equivalent (tested with Sequel, DataMapper, and ActiveRecord; none seem to have the db:test:prepare). So, my question is: how do I get integrated database tests running within Padrino?
From this forum post, I discovered why db:test:prepare is this weird, arbitrary rake task one needs to run: it has to do with the test environment (versus development and production). In Padrino, this translates to the following code, which is a bit more obscure, but more intuitive as well:
$ padrino rake sq:migrate:up -e test
This tells Padrino to create the table for the test database, which allows the spec(s) to pass.
Related
Running tests on Rails on the built Sample App (Michael Hartl Rails 5), When running tests I get the above error, which suggests it can't find the table 'users', it's available in my db migrate folder and also listed in the development.sqlite3 file, So not sure what the issue is
Tried the recommended fixes running rake db:test:prepare, rails db:migrate:reset testing to see if User.new(name: 'foo') creates a user neither have fixed the problem and the latter creates fine in the console so can't understand why it can't find the table
_create_users.rb
def change
create_table :users do |t|
t.string :name
t.string :email
t.timestamps
end
end
end
tests to run errors run when attempting 'rails test:mailers' and more when using 'rails test'
db:migrate
SQLite
It's important to remember that each environment in Rails has its own database. Just because your application is working when you're doing development (RAILS_ENV=development), it doesn't mean the database is there when running tests (RAILS_ENV=test).
You may simply need to prepare your test database (create it and migrate it):
# Drop any test DB you already have
bundle exec rake db:drop RAILS_ENV=test
# Create a clean fresh one
bundle exec rake db:create RAILS_ENV=test
# Import the Schema from your schema.rb, rather than run all migrations
bundle exec rake db:schema:load RAILS_ENV=test
If you do the above and then run your tests, they should work as expected.
I tried to convert from FactoryGirl to FactoryBot. This should not be a big issue but i do not get it to work. The code:
Added to Gem File
gem 'factory_bot'
Added to spec_helper
FactoryBot.definition_file_paths = %w(spec/factories)
FactoryBot.find_definitions
config.include FactoryBot::Syntax::Methods
Factory
FactoryBot.define do
factory :user do
first_name 'John'
last_name 'Doe'
birthdate { 21.years.ago }
admin false
end
end
When i try to run a rspec test i get following error:
NoMethodError: undefined method 'first_name' in 'user' factory!
Method_missing at C:/jruby-9.1.17.0/lib/ruby/gems/shared/gems/factory_bot-5.0.2/lib/factory_bot/definition_proxy.rb:97
block in (root) at <path to factory>
It seems to me the gem is correctly loaded into the project, the factoryBot code is executed. But for some reason it does not recognize the structure of the factory.
Note:
- I did a bundle install/update
Like people said in the comments static attributes like first_name 'John' have been deprecated on v4 (check this guide) and then removed on v5, the alternative is to make them like dynamic attributes: first_name { 'John' }.
They even included a Rubocop to help you fix all of your factories:
rubocop \
--require rubocop-rspec \
--only FactoryBot/AttributeDefinedStatically \
--auto-correct
My recommendation is to migrate slowly but surely, go from FactoryGirl to FactoryBot using a similar version, run your specs, check for all deprecation warnings, run the custom Rubocop to auto-correct your factories, then only migrate major versions after reading the changelog.
I agree the message could be a bit better, usually the main goal of deprecation is to simplify code and reduce branching logic, so once the deprecation warning was there for enough time and it is time to remove it, any detection of the old usage would be extra code that had to be removed, common result in open source projects.
Glad you found your way out.
I'm trying to perform database related operations on my newly upgraded app(Rails 5) and I'm unable to perform destructive database commands locally.
rails db:reset or rails db:drop .
The trace results with the following data,
rails db:drop --trace
** Invoke db:drop (first_time)
** Invoke db:load_config (first_time)
** Execute db:load_config
** Invoke db:check_protected_environments (first_time)
** Invoke environment (first_time)
** Execute environment
** Invoke db:load_config
** Execute db:check_protected_environments
rails aborted!
ActiveRecord::NoEnvironmentInSchemaError:
Environment data not found in the schema. To resolve this issue, run:
bin/rails db:environment:set RAILS_ENV=development
What I've tried so far are,
Setting bin/rails db:environment:set RAILS_ENV=development, doesn't change anything still the error occurs.
Setting Environment variable manually to development.
None of these helped. I'm Looking for a fix or workaround.
Two Fixes to ActiveRecord::NoEnvironmentInSchemaError
The other answers here describe the problem very well, but lack proper solutions. Hoping this answer helps someone experiencing this issue.
Why this error is happening
This incorrect error message is a result of this pull request designed to prevent destructive actions on production databases. As u/pixelearth correctly points out, Rails 4.2 defines the 'key' field in the ar_internal_metadata table to be an integer, and Rails 5+ (including Rails 6) expects this to be a string with the value, environment. When Rails 5 and Rails 6 run this safety check, they incorrectly raise an ActiveRecord::NoEnvironmentInSchemaError as the code is incompatible with the Rails 4 schema format.
Fix #1: Override the safety check in Rails 5+
**Please remember, the safety check was implemented as a result of so many users dropping their production databases by accident. As the question describes, the operations are destructive.
From the terminal:
rails db:drop RAILS_ENV=development DISABLE_DATABASE_ENVIRONMENT_CHECK=1
# and/or
rails db:drop RAILS_ENV=test DISABLE_DATABASE_ENVIRONMENT_CHECK=1
As noted here, the DISABLE_DATABASE_ENVIRONMENT_CHECK=1 flag disables the environment check. After, you can run a rake db:create RAILS_ENV=development, for example, to recreate your database with the correct schema in the ar_internals_metadata table.
Fix #2: Revert to Rails 4, drop database, go back to Rails 5+ and recreate
From the terminal:
git log
# grab the commit hash from before the upgrade to Rails 5+
git checkout **hash_from_rails_4**
rake db:drop RAILS_ENV=development
rake db:drop RAILS_ENV=test
git checkout master
# now things should work
rails db:migrate
Again, please ensure you are not pointing at a production database when overriding this functionality. Alternatively, it would be possible to directly modify the schema of this table. If you're experiencing this error in production, you may need to take this approach.
This happened because, for some reason, your table ar_internal_metadata got deleted or changed.
If you cannot drop the database via the command line, you need to do it via your DBMS or database client.
Then, just run rails db:create db:migrate to create and run the migrations.
For posterity, my issue was that this schema was generated by a rails 4 app and the current app using it is rails 5. With rails 5 the structure of the ar_internal_metadata table has changed slightly. The key field needs to be a string and contain the word 'environment', not an integer. This error only goes away when this is changed.
It should look like this in Rails 5
ie, change the type of ar_internatl_metadata #key to string...
My situation is a bit uncommon involving a rails 4 app and a rails 5 app sharing the same db. When I need to "update", I have a task:
puts "Modifying Rails 4 schema to fit Rails 5 schema"
file_name = "./db/schema.rb"
rails_4_ar_internal_metadata = 'create_table "ar_internal_metadata", primary_key: "key", force: :cascade do |t|'
rails_5_ar_internal_metadata = 'create_table "ar_internal_metadata", primary_key: "key", id: :string, force: :cascade do |t|'
new_schema = File.read(file_name).gsub(rails_4_ar_internal_metadata, rails_5_ar_internal_metadata)
File.write(file_name, new_schema)
Console rails
bin/rails db:environment:set RAILS_ENV=development
I had
bundle exec rake db:drop
rake aborted!
ActiveRecord::NoEnvironmentInSchemaError:
Environment data not found in the schema. To resolve this issue, run:
rails db:environment:set RAILS_ENV=development
And, indeed, simply running rails db:environment:set RAILS_ENV=development made the problem go away.
Why did this happen?
It happened because I tried to drop the database and create it / migrate it, however, I had a syntax error in the migration (datatype and column name in the wrong places). Check your migration file for any silly errors
Specifically I had
t.submitted :boolean, default: false
instead of
t.boolean :submitted, default: false
I'm trying to replace fixture generation with factories using rails3-generators:
https://github.com/indirect/rails3-generators#readme
The gem is included in my Gemfile and has been installed:
# Gemfile
gem 'rails3-generators', :group => :development
I added the following to application.rb:
# application.rb
config.generators do |g|
g.stylesheets false
g.fixture_replacement :factory_girl
end
Yet 'rails g model Insect' is still generating fixtures ('insects.yml'). Is this working for others using Rails 3.0.4 and rails3-generators 0.17.4?
'rails g' shows the new generators available (such as Authlogic and Koala), but 'rails g model' still lists fixtures and doesn't refer to factories.
What else should I add to get this to work? Thanks.
Edit: I ran the gem's test suite, which includes a test for this, and it passes. No clue why it doesn't work with my app.
Edit2: I tried again with a test project and get the same result: fixtures instead of factories. If anybody could confirm whether this works for them with Rails 3.0.4 and rails3-generators 0.17.4, that would be helpful too because it would imply that I'm doing something wrong with my projects.
Edit3: It works if I run 'rails g model Insect -r factory_girl'. I thought the generator configuration in application.rb was supposed to take care of that, so this seems to be the source of the problem.
Searching around I found the following, which may help:
Try specifying a directory option for factory_girl's factories:
config.generators do |g|
g.stylesheets false
g.fixture_replacement :factory_girl, :dir => "spec/factories" # or test/factories, as the case may be
end
If you're using Test::Unit, try the following:
config.generators do |g|
g.stylesheets false
g.test_framework :test_unit, :fixture_replacement => :factory_girl
end
In both cases you will still need the rails3-generators gem, although there is a push to get that functionality into factory_girl_rails.
This Rails bug indicates that, at some point, the g.fixture_replacement code may not have worked right. Perhaps a test in 3.0.5 is in order. :)
A short update 9 years later:
instead of "factory_girl_rails" (which is deprecated now) use "factory_bot_rails".
Now, the factory gets created automagically:
$ rails g model tester name:string
Running via Spring preloader in process 31467
invoke active_record
create db/migrate/20200327152901_create_testers.rb
create app/models/tester.rb
invoke rspec
create spec/models/tester_spec.rb
invoke factory_bot
create spec/factories/testers.rb
I use rails 5.2.4, but this should also work with rails 6.
I'm new to Ruby, and I've been trying to learn Rake, RSpec, and Cucumber. I found some code that will help me test my Rake tasks, but I'm having trouble getting it to work. I was told here: http://blog.codahale.com/2007/12/20/rake-vs-rspec-fight/ to drop this:
def describe_rake_task(task_name, filename, &block)
require "rake"
describe "Rake task #{task_name}" do
attr_reader :task
before(:all) do
#rake = Rake::Application.new
Rake.application = #rake
load filename
#task = Rake::Task[task_name]
end
after(:all) do
Rake.application = nil
end
def invoke!
for action in task.instance_eval { #actions }
instance_eval(&action)
end
end
instance_eval(&block)
end
end
into my spec_helper.rb file.
I've managed to take this code out and run it in my cucumber steps like this:
When /^I run the update_installers task$/ do
#rake = Rake::Application.new
Rake.application = #rake
load "lib/tasks/rakefile.rb"
#task = Rake::Task["update_installers"]
for action in #task.instance_eval { #actions }
instance_eval(&action)
end
instance_eval(&block)
Rake.application = nil
end
but when I try to get things working in rspec, I get the following error.
ArgumentError in 'Rake task
install_grapevine should install to
the mygrapevine directory'
wrong number of arguments (1 for 2)
/spec/spec_helper.rb: 21:in instance_eval'
/spec/spec_helper.rb: 21:inblock in invoke!'
/spec/spec_helper.rb: 20:in each'
/spec/spec_helper.rb: 20:ininvoke!'
/spec/tasks/rakefile_spec.rb:12:in `block (2 levels) in
'
Unfortunately, I've got just under a week of ruby under by belt, so the metaprogramming stuff is over my head. Could anyone point me in the right direction?
This works for me: (Rails3/ Ruby 1.9.2)
When /^the system does it's automated tasks$/ do
require "rake"
#rake = Rake::Application.new
Rake.application = #rake
Rake.application.rake_require "tasks/cron"
Rake::Task.define_task(:environment)
#rake['cron'].invoke
end
Substitute your rake task name here and also note that your require may be "lib/tasks/cron" if you don't have the lib folder in your load path.
I agree that you should only do minimal work in the Rake task and push the rest to models for ease of testing. That being said I think it's important to ensure that the code is ACTUALLY run in my cron tasks during my integration tests so I think very mild testing of the rake tasks is justified.
Since testing rake is just too much for me, I tend to move this problem around. Whenever I find myself with a long rake task that I want to test, I create a module/class in lib/ and move all the code from the task there. This leaves the task to a single line of Ruby code, that delegates to something more testable (class, module, you name it). The only thing that remains untested is whether the rake task invokes the right line of code (and passes the right parameters), but I think that is OK.
It might be useful to tell us which is the 21nd line of your spec_helper.rb. But given that the approach you posted digs deep in rake (referring to its instance variables), I would entirely abandon it for what I suggested in the previous paragraph.
I've just spent a little while getting cucumber to run a rake task so I thought I'd share my approach. Note: This is using Ruby 2.0.0 and Rake 10.0.4, but I don't think the behaviour has changed since previous versions.
There are two parts to this. The first is easy: with a properly set up instance of Rake::Application then we can access tasks on it by calling #[] (eg rake['data:import']). Once we have a task we can run it by calling #invoke and passing in the arguments (eg rake['data:import'].invoke('path/to/my/file.csv').
The second part is more awkward: properly setting up an instance of Rake::Application to work with. Once we've done require 'rake' we have access to the Rake module. It already has an application instance, available from Rake.application, but it's not yet set up — it doesn't know about any of our rake tasks. It does, however, know where to find our Rakefile, assuming we've used one of the standard file names: rakefile, Rakefile, rakefile.rb or Rakefile.rb.
To load the rakefile we just need to call #load_rakefile on the application, but before we can do that we need to call #handle_options. The call to #handle_options populates options.rakelib with a default value. If options.rakelib is not set then the #load_rakefile method will blow up, as it expects options.rakelib to be enumerable.
Here's the helper I've ended up with:
module RakeHelper
def run_rake_task(task_name, *args)
rake_application[task_name].invoke(*args)
end
def rake_application
require 'rake'
#rake_application ||= Rake.application.tap do |app|
app.handle_options
app.load_rakefile
end
end
end
World(RakeHelper)
Pop that code into a file in features/support/ and then just use run_rake_task in your steps, eg:
When /^I import data from a CSV$/ do
run_rake_task 'data:import', 'path/to/my/file.csv'
end
The behavior might have changed since the correct answer was posted. I was experiencing problems executing two scenarios that needed to run the same rake task (only one was being executed despite me using .execute instead of .invoke). I thought to share my approach to solve the issue (Rails 4.2.5 and Ruby 2.3.0).
I tagged all the scenarios that require rake with #rake and I defined a hook to setup rake only once.
# hooks.rb
Before('#rake') do |scenario|
unless $rake
require 'rake'
Rake.application.rake_require "tasks/daily_digest"
# and require other tasks
Rake::Task.define_task(:environment)
$rake = Rake::Task
end
end
(Using a global variable is suggested here: https://github.com/cucumber/cucumber/wiki/Hooks#running-a-before-hook-only-once)
In the step definition I simply called $rake
# step definition
Then(/^the daily digest task is run$/) do
$rake['collector:daily_digest'].execute
end
Any feedback is welcome.