I know in Rails application, I can write tests for controllers and models by using Rspec.
But:
How about to test some rake task? What is the good way to test some rake task?
How about to test a cron job which run certain rake task every day at a fixed time?
Can Rspec also be used for above two scenarios in Rails app development or are there some other ways to implement those tests?
In addition:
I have a rake task which is used to update the database of the Rails app by fetching data from another database and insert to the app database (clean the app database first of course)
I would like to test these, how to do it?
Instead of having code in your rake tasks, do something like this:
desc "Charge Customers Daily"
task :charge_customers => :environment do
CustomerCharges.create
end
That way, you can write rspec tests in the customer_charges_spec.rb file as you normally would.
Maybe this helps :
http://www.philsergi.com/2009/02/testing-rake-tasks-with-rspec.html
To test a cron job, you can just redirect to a log file on cron itself, like :
command > /tmp/log.txt 2>&1
Generally, if you intend on doing db insertions and stuff in a rake task, i would reconsider and write that as a separate ruby module. I think it's much more flexible this way.
Related
I have two Rails apps that use the same database. One app is managing the database through migrations but the other is just accessing it.
For some reason when I run tests with RSpec in the app that is not managing the database it drops the database before running the tests. But because this app does not know how to recreate the database all tests will fail.
How can I tell RSpec not to drop the database, just use it as it is?
If you don't need to migrate the database you can redefine rspecs-rails
spec:prepare task like this:
lib/tasks/patch_rspec_rails.rb
Rake::Task["spec:prepare"].clear
namespace :spec do
task :prepare do
ENV['RACK_ENV'] = ENV['RAILS_ENV'] = 'test'
end
end
The original spec:prepare task callstest:prepare, which setups the db.
The task test:prepare exists since Rails 4.0 (or maybe earlier). This task also exists within Rails 5.0. It is a hook for railsties to add test dependent setups. You can check its definition with rake -W test:prepare. That
the task is hit you can check with rake --trace spec.
ActiveRecord uses this task to check the migration state and setup the db.
When this task is not called, no db will be dropped or created.
But be aware, when some other gem uses test:prepare as a hook too plug into tests, it will not work.
Edit:
Since Rails 4.1 you can set config.active_record.maintain_test_schema = false within config/environments/test.rb. This way Rails should no longer try to migrate your test schema.
Ideally RSpec should be reinitialisation the database for testing to ensure your environment is in a reliably, predictable state.
What you could do is for the Rails app that isn't managing the database carry out a rake db:schema:dump to generate the schema.rb which will then be used by RSpec - of course make sure that your database.yml test configuration isn't pointing to your live database.
I know that this isn't technically a solution to your question but it should prevent the underlying issue which is causing your tests to fail.
I have a bunch of rake tasks that modify models in my rails project. They all work just fine in development, but in production they fail to load up associated model and service classes.
The problem seems to come from the :environment declaration. My tasks take the form
task :my_task => :environment do
#modify models
end
The documentation says that :environment loads the rails environment so that you can interact with any file in the rails system, but apparently this is not the case in production?
Is there a way to load needed files in production? Or should I not be using the :environment task at all? Seems really weird to have the code behave one way in development and another in production (testing this is gonna be a pain).
Seems to be an issue with the way rake tasks don't eager-load. This answer may be the droids you're looking for: Rails 3 rake task can't find model in production
I start with a test database containing the schema but with no data in the tables. I run a test like so
cd test/
ruby unit/directive_test.rb
I get failures indicating that the code found no data in the data tables. However, I look at the tables after running that test and the data is now in the the table. In fact, if I immediately run the test again I get no failures.
So it appears that the fixture is being loaded into the table too late for one of my modules to find it.
When are the fixtures loaded? After or before the app/model/*.rb files are executed?
If it is after the models are executed is there a way to delay the loading?
This issue is also relevant when running rake test:units since that task clears the test data after it finished.
first of all see this thread and see if it can help you.
if you run the rail task rake test:units it will for sure load all fixtures before you run your code. if you are running just the test, and your unit test has no reference to the test_help.rb probably it is not loading the fixtures. You should try to run it through the rake tasks.
Another tip that i give you is that you forget the fixtures and use factories (here i recommend factory_girl). It takes sometime to get used, but it worth. Fixtures are too hard to manage, update and etc.
there is another post explaing little about the concept behind factories.
I am currently trying to automate the deployment process of our rails app as much as possible, so that a clean build on the CI server can trigger an automated deployment on a test server.
But I have run into a bit of a snag with the following scenario:
I have added the friendly_id gem to the application. There's a migration that creates all the necessary tables. But to fill these tables, I need to call a rake task.
Now, this rake tasks only has to be called once, so adding it to the deployment script would be overkill.
Ideally, I am looking for something like migrations, but instead of the database, it should keep track of scripts that need to be called during a deployment. Does such a beast already exist?
Looks like after_party gem does exactly what you want.
I can't think of anything that does exactly what you want, but if you just need to be able to run tasks on remote servers in a one off fashion you could always use rake through capistrano.
There's an SO question for that here: How do I run a rake task from Capistrano?, which also links to this article http://ananelson.com/said/on/2007/12/30/remote-rake-tasks-with-capistrano/.
Edit: I wonder if it's possible to create a migration which doesn't do any database changes, but just invokes a rake task? Rake::Task["task:name"].invoke. Worth a try?
I would consider that running that rake task is part of the migration to using friendly_id. Sure, you've created the tables, but you're not done yet! You still have to do some data updates before you've truly migrated.
Call the rake task from your migration. It'll update the existing data and new records will be handled by your app logic in the future.
For ad hoc Rails tasks we have a few implementation alternatives, chief among which would seem to be:
script/runner some_useful_thing
and:
rake some:other_useful_thing
Which option should I prefer? If there's a clear favourite then when, if ever, should I consider using the other? If never, then why would you suppose it's still present in the framework without deprecation warnings?
The difference between them is that script/runner boots Rails whereas a Rake task doesn't unless you tell it to by making the task depend on :environment, like this:
task :some_useful_task => :environment do
# do some useful task
end
Since booting Rails is expensive, it might be worth skipping if you can avoid it.
Other than that, they are roughly equivalent. I use both, but lately I've used script/runner executing a script separately more.
Passing parameters to a rake task is a pain in the butt, to say the least. You either need to resort to environment variables or a very hackish parameter system that is not intuitive and has lots of caveats.
If your task needs to handle command line arguments gracefully then writing a script is the way to go.
Luke Francl mentions script/runner booting up Rails. That's true. But if you don't want to boot up rails then just run the script as is without script/runner. So the only real difference between scripts and rake tasks are their aesthetics. Choose whatever feels right to you.
I use rake tasks for little tasks (one or two lines). Anything more complicated goes into the script/ directory. I'll break this rule if I think other developers will expect the code to live in one place over another.
FWIW there seems to be some movement away from using script runner in favor of rake:
Update (4/25/2009): I recommend using rake tasks as opposed to script/runner for recurring tasks.
Also, as per this post you can use rake for recurring tasks just fine:
If I then wanted this to run nightly on my production database at midnight, I might write a cronjob that looks something like this:
0 0 * * * cd /var/www/apps/rails_app/ && /usr/local/bin/rake RAILS_ENV=production utils:send_expire_soon_emails
Corrected based on comment 2 down. Give them the karma!
FWIW - Rails 3.0+ changes how you initialize the Rails system in a standalone script.
require File.dirname(__FILE__) + '/config/environment'
As mentioned above you can also do:
rails runner script/<script name>
Or put all the code in a Rake task, but I have a lot of legacy code from Rails 2; so I didn't want to go down that path immediately.
Each has its advantages and disadvantages.
One thing I've done is just write normal ruby scripts and put them in the script/maintenance directory.
All you need to do to load rails and get access to all your models, etc, is put require '../../config/environment.rb' at the top of your file, then you're away.
For one off commands script/runner can be fine. For anything repeated, a rake task is easier in the long-run, and has a summary if you forget what it does.
In Rails 3.0+, the config/environment.rb requires the config/application.rb, that requires the config/boot.rb.
So, to load an app in Rails 3, you still only have to require the environment.rb
I got the impression script/runner was primarily for periodic tasks. E.g., a cron job that runs:
SomeClass.update_from_web('http://www.sourcefordata.gov/')