How to add pages to Refinery CMS testing dummy app database - ruby-on-rails

I created a Refinery CMS extension following the extension guide and the extension testing guide.
Some rspec unit tests pass and http://localhost/the_extension loads in a web browser. But now tests are failing because the dummy app has no pages (or any other db tables).
I tried just copying the dummy_dev file to dummy_test (and a whoooole bunch of other things), and that works (sort of) because when I run the dummy app (cd spec/dummy; rvmsudo rails s -p 80 -e test) the pages load in my browser, and when I query the pages table (sqlite3 dummy_test 'select * from refinery_pages;) there are pages.
But every time I run cd vendor/extensions/the_extension; bundle exec rake spec it deletes all the entries in the page table.
I tried adding this to spec/spec_helper.rb:
# Copy the prototype test database to the test database.
FileUtils.cp File.expand_path('../dummy_test_db_prototype', __FILE__), File.expand_path('../dummy/dummy_test', __FILE__)
But by the time the specs are run the test db has been deleted. The db is deleted after the specs are read in, because if I put the following at the bottom of spec/features/refinery/the_extension/the_extension_spec.rb the db still has pages:
# DEBUG
puts 'Querying test db:'
system "sqlite3 /some_app/vendor/extensions/the_extension/spec/dummy/dummy_test 'select * from refinery_pages;'"
puts 'Done querying.'
How do I make sure there are pages in the test database when the tests run?

describe "stuff" do
it "should do stuff" do
before { Refinery::Page.create([{ title: 'home', link_url: '/' }]) }
...
end
end

Related

Rake task failing to load :environment properly

I'm running a custom rake task...
namespace :import do
desc "Import terms of service as HTML from stdin"
task :terms => :environment do
html = STDIN.read
settings = ApplicationWideSetting.first
settings.terms_and_conditions = html
if settings.save
puts "Updated terms of service"
else
puts "There was an error updating terms of service"
end
end
end
The model ApplicationWideSetting is reported as undefined when running the task in the production environment. However, when running the task on other environments (ie. development, staging, test.) the task runs fine.
Running the process in rails console, in all environments, completes ok.
Does anyone know what's going on, things I could check?
note: I ran the task with
puts Rails.env
To check the shell environment var RAILS_ENV was getting set/read correctly. I've also tried both with and without the square brackets around the :environment dependency declaration.
additional info: Rails v3.2.14
further info: I've setup a completely fresh rails app, and the script works fine in any environment. Since the install in question is a real production environment, I'll have to setup another deploy and check it thoroughly. More info as I find it.
In a nutshell, Rails doesn't eager load models (or anything else) when running rake tasks on Production.
The simplest way to work with a model is to require it when you begin the rake task, and it should work as expected, in this case:
# explicitly require model
require 'application_wide_setting'
It's possible to eager load the entire rails app with:
Rails.application.eager_load!
However, you may have issues with some initializers (ie. devise)

Problem using `rake test`

I wonder how to setup testing in my rails apps. When I run rake test, first thing odd, it launch a bunch of CREATE TABLE against my dev. database (hum.. do not like this..). So I launch rake test RAILS_ENV=test and I even try bundle exec rake test RAILS_ENV=test. Now, the CREATE TABLE is against my test database but all fails with this error :
** Execute test:units
test/unit/category_test.rb:5:in `test': unknown command 't' (ArgumentError)
from test/unit/category_test.rb:5:in `<class:CategoryTest>'
I have used basic generator in Rails 3 and do not change anything. So I have this in caterogy_test.rb :
require 'test_helper'
class CategoryTest < ActiveSupport::TestCase
# Replace this with your real tests.
test "the truth" do
assert true
end
end
I use Rails 3.0.7 and basic config.
Any ideas ?
EDIT
I am becoming crazy, made a lot of tries, neither seems to work. When I start a new application with a few things, rake test works fine but when I try this on my current one, it launch always against my dev. db and do not work at all. I have tried to edit the test files, to revert them back, try to remove/setup test db with different ways, try different rake version, compare a lot of things on one side my current application and on the other a brand new one... Found nothing.. Help !
EDIT 2
Sounds lame, but is it normal that rake does the same thing than rake test ?
EDIT 3
Sounds odds, while I continue to work on what's wrong, I realize that every-time I run rake test, it does stuff on the dev environment and not the test one (watching the logs). It does this on my computer OSX and on our server FreeBSD for all the Rails 3.0.7 apps. Are you sure rake test is supposed to work on the test environment by default ?
EDIT 4
Please help!
EDIT 5 - SUMMARY
When running rake test in my computer or on our server in Rails 3.0.7 with different apps it does the following :
run CREATE TABLE and INSERT INTO migration against the dev. db.
do not empty the dev. db.
development.log gets written not the test.log
also an issue with the error unknowm comman 't' with one specific app.
EDIT 6 - db config
Nothing change from the default yet : https://gist.github.com/1006199
EDIT 7
rake db:test:prepare --trace -> nothing break (but keep printing (first_time)
https://gist.github.com/1007340
With RAILS_ENV="test" for rake, everything goes fine. It write on the test logs.
ruby -I test test/unit/category_test.rb same erros than with rake, but no write on the dev. or test logs.
a bunch of unorderd answers:
the "CREATE TABLE" statements usually means that your test_db is created from scratch (by default, before test task, a db:migrate is launched). are you sure they're called on dev_db?
also check your config/database.yml to see if there's some typo (eg: using same table for test and dev environments)
it looks like there's an error in some of your migration files (that 't' error remember blocks in migrations).
"rake test" is the default task, that's why it's run when you just launch "rake" without arguments.
EDIT:
according on what I see on edits, from 5 and above, it looks like you have some issue with environment files. so try to double-check:
* config/environments/test.rb
* config/application.rb
* config/environment.rb
if with RAILS_ENV="test", everything goes fine, then I'm almost sure you have changed some default behaviour in your app (configs, env variables, any particular gem?)
also, in your test/test_helper.rb, add RAILS_ENV='test' at the beginning of file, this should force test environment.
I had that same error message, except to me it said: in `test': unknown command 'i' (ArgumentError).
The 'fix' or 'workaround' was to simply use:
$> bundle exec rake test
instead of using 'rake test'

How do I prepare test database(s) for Rails rspec tests without running rake spec?

After significant troubleshooting, I figured out that I needed to run rake spec once (I can abort with control-c) before I can run rspec directly (e.g. on a subset of our specs). We are running Rails 3.0.7 and RSpec 2.5.0.
Clearly, rake is running some important database setup tasks / code (we have custom code in the root level rails Rakefile and possibly other places).
How can I run the rake test database setup tasks / code without running rake spec?
In addition to being able to run rspec on a subset of files, I am using specjour to spread our specs across multiple cores (haven't had success with spreading them across the LAN yet), but I see the same behavior as for running rspec directly: I need to run rake spec on each test database (assuming two cores) before specjour works:
rake spec TEST_ENV_NUMBER=1
control-c (after tests start)
rake spec TEST_ENV_NUMBER=2
control-c (after tests start)
specjour
Note: my config/database.yml has this entry for test (as is common for the parallel testing gems):
test:
adapter: postgresql
encoding: unicode
database: test<%=ENV['TEST_ENV_NUMBER']%>
username: user
password:
parallel_tests seems to set up its databases correctly, but many of our specs fail.
I should also mention that running specjour prepare causes Postgres to log errors that it can't find the databases, but it creates them (without tables). On a subsequent run, no errors are logged, but also no tables are created. It is possible that my whole issue is simply a bug in prepare, so I reported it on github.
I think that I can run arbitrary code on each specjour test database by setting Specjour::Configuration.prepare in .specjour/hooks.rb, so if there's any rake tasks or other code that I need to run, it may work there.
I would recommend dropping your test database, then re-create it and migrate:
bundle exec rake db:drop RAILS_ENV=test
bundle exec rake db:create RAILS_ENV=test
bundle exec rake db:schema:load RAILS_ENV=test
After these steps you can run your specs:
bundle exec rspec spec
gerry3 noted that:
A simpler solution is to just run rake db:test:prepare
However, if you're using PostgreSQL this wont work because the rails environment gets loaded, which opens a database connection. This causes the prepare call to fail, because the DB cannot be dropped. Tricky thing.
I had a similar problem setting up the CI system at work, so I gradually worked up a system to handle this. It may not be the best solution, but it works for me in my situation and I'm always on the lookout for better ways to do things.
I have a test database that I needed setup, but also needed seeded data loaded for our tests to work.
The basics of troubleshooting rake tasks is to run rake with the --trace option to see what is happening under the hood. When i did this, I found that running rake spec did a number of things that I could replicate (or modify as I saw fit) in a custom rake task.
Here's an example of what we do.
desc "Setup test database - drops, loads schema, migrates and seeds the test db"
task :test_db_setup => [:pre_reqs] do
Rails.env = ENV['RAILS_ENV'] = 'test'
Rake::Task['db:drop'].invoke
Rake::Task['db:create'].invoke
result = capture_stdout { Rake::Task['db:schema:load'].invoke }
File.open(File.join(ENV['CC_BUILD_ARTIFACTS'] || 'log', 'schema-load.log'), 'w') { |f| f.write(result) }
Rake::Task['db:seed:load'].invoke
ActiveRecord::Base.establish_connection
Rake::Task['db:migrate'].invoke
end
This is only an example, and specific to our situation, so you'll need to figure out what needs to be done to get your test db setup, but it is quite easy to determine using the --trace option of rake.
Additionally, if you find the test setup is taking too long (as it does in our case), you can also dump the database into .sql format and have the test database pipe it directly into mysql to load. We save several minutes off the test db setup that way. I don't show that here because it complicates things substantially -- it needs to be generated properly without getting stale, etc.
HTH
The provided solutions all require to load the Rails environment, which is, in most cases, not the desired behaviour due to very large overhead and very low speed. DatabaseCleaner gem is also rather slow, and it adds another dependency to your app.
After months of chagrin and vexation thanks to reasons vide supra, I have finally found the following solution to be exactly what I need. It's nice, simple and fast. In spec_helper.rb:
config.after :all do
ActiveRecord::Base.subclasses.each(&:delete_all)
end
The best part about this is: It will only clear those tables that you have effectively touched (untouched Models will not be loaded and thus not appear in subclasses, also the reason why this doesn't work before tests). Also, it executes after the tests, so the (hopefully) green dots will appear right away.
The only downside to this is that if you have a dirty database before running tests, it will not be cleaned. But I doubt that is a major issue, since the test database is usually not touched from outside tests.
Edit
Seeing as this answer has gained some popularity, I wanted to edit it for completeness: if you want to clear all tables, even the ones not touched, you should be able to do something like the "hacks" below.
Hack 1 - pre-loading all models for subclasses method
Evaluate this before calling subclasses:
Dir[Rails.root.join("app", "models", "**", "*.rb")].each(&method(:require))
Note that this method may take some time!
Hack 2 - manually truncating the tables
ActiveRecord::Base.connection.tables.keep_if{ |x| x != 'schema_migrations' }
will get you all table names, with those you can do something like:
case ActiveRecord::Base.configurations[Rails.env]["adapter"]
when /^mysql/, /^postgresql/
ActiveRecord::Base.connection.execute("TRUNCATE #{table_name}")
when /^sqlite/
ActiveRecord::Base.connection.execute("DELETE FROM #{table_name}")
ActiveRecord::Base.connection.execute("DELETE FROM sqlite_sequence where name='#{table_name}'")
end
It appears that in Rails 4.1+, the best solution is simply to add ActiveRecord::Migration.maintain_test_schema! in your rails_helper after require 'rspec/rails'.
i.e. you don't have to worry about having to prepare the database anymore.
https://relishapp.com/rspec/rspec-rails/docs/upgrade#pending-migration-checks
In a spring-ified Rails 4 app, my bin/setup is usually augmented to contain
puts "\n== Preparing test database =="
system "RAILS_ENV=test bin/rake db:setup"
This is very similar to leviathan's answer, plus seeding the test DB, as
rake db:setup # Create the database, load the schema, and initialize with the seed data
(use db:reset to also drop the database first)
As the comment mentions, if we want to drop the DB first, rake db:reset does just that.
I also find that this provides more feedback when compared to rake db:test:prepare.
I started by dropping my test database
rake db:drop RAILS_ENV=test
when trying to create a new test database I ran into an issue because my user account was not the same as the account that owns the databases so I created the database in PostgreSQL instead.
type psql in the command prompt and then run the below to create a test database that uses an account other than your own.
CREATE DATABASE your_database_name OWNER your_db_owner;
then run your migrations in the test environment.
rake db:migrate RAILS_ENV=test

"rake spec" migrates the database every time

When I run any of the rspec tasks via rake, the database seems to be dropped and migrated, but if I run them via script/spec path/to/spec, it doesn't. Is there an option I can set so the rake spec doesn't touch the database?
It shouldn't be running any migrations, only importing db/schema.rb into your test database. This is the expected behavior so your tests use a fresh copy of the database schema before they run. What is your reasoning for not wanting it to refresh the test database?
For what I do I want it off permanently. So with rspec 2.5.0 and rails 3:
Copy rspec.rake to your apps /lib/tasks folder from:
~/.rvm/gems/ruby-1.8.7-p302/gems/rspec-rails-2.5.0/lib/rspec/rails/tasks/rspec.rake
Add this to the top of the file:
Rake::TaskManager.class_eval do
def remove_task(task_name)
#tasks.delete(task_name.to_s)
end
end
def remove_task(task_name)
Rake.application.remove_task(task_name)
end
remove_task 'spec'
Find and edit this line to force a noop:
spec_prereq = :noop #Rails.configuration.generators.options[:rails][:orm] == :active_record ? "db:test:prepare" : :noop
I had this same problem also when running rspec from the command line. In my cases I was working with an legacy database that had no migrations, so the tests would fail because migrations could not be run.
The solution was to edit the spec/spec_helper.rb file and delete the following line:
ActiveRecord::Migration.check_pending! if defined?(ActiveRecord::Migration)
After that the tests ran without failing.

Where does Rails store data created by saving activerecord objects during tests?

Where does Rails store data created by saving activerecord objects during tests?
I thought I knew the answer to that question: obviously in the _test database. But it looks like this is not true!
I used this system to test what's happening to saved ActiveRecord data during rspec tests:
$ rails -d mysql test
$ cd test
$ nano config/database.yml ...
... create mysql databases test_test, test_development, test_production
$ script/generate rspec
$ script/generate rspec_model foo
edit Foo migration:
class CreateFoos
$ rake db:migrate
edit spec/models/foo_spec.rb:
require File.expand_path(File.dirname(__FILE__) + '/../spec_helper')
describe Foo do
before(:each) do
#valid_attributes = {
:bar => 12345
}
end
it "should create a new instance given valid attributes" do
foo = Foo.new(#valid_attributes)
foo.save
puts "sleeping..."
sleep(20)
end
end
$ rake spec
When you see "sleeping...", change to another open terminal with a mysql session conneted to the test_test database and do:
mysql> select * from foos;
Empty set (0.00 sec)
Why doesn't the mysql session show any records in the test_test database while the test is running?
Items in the test database are erased by default after each test is run, by design. This is done to make sure that each of your tests has its own sandbox to play in that doesn't cause any interactions with the tests before it.
Again, this is by design. You don't want tests that are manipulating the same set of data (or rely on synchronous execution), because there is no guarantee of execution order.
However, I believe if you modify you test/test_helper.rb file to say this:
self.use_transactional_fixtures = false
instead of
self.use_transactional_fixtures = true
It will cause the data in your test database to persist.
ALSO: My advice is specifically designed to work with Test::Unit, not RSpec. However, I imagine that there is a similar setting your spec_helper.rb you should be looking for.
You can observe records being added to the test database with:
tail -f log/test.log
You should see the transactions flying by as the tests are run.
"But why does the mysql query show no data in the database while the test is running?"
Because it's in a transaction. If you turn transactional fixtures off your tests will run much slower than before.

Resources