I'm using minitest for one of my projects, and I can't seem to get the Rake TestTask to actually run the files.
require 'rake'
require 'rake/testtask'
task :mytest do
Rake::TestTask.new do |t|
t.test_files = Dir.glob('test/model/*_test.rb')
t.verbose = true
puts t.inspect
puts '-------------------------------------'
end
end
when I run this task rake mytest, I get the following output :
projects#webdev-local:/home/projects/framework# rake mytest
#<Rake::TestTask:0x00000001775050 #name=:test, #libs=["lib"], #pattern=nil,
#options=nil, #test_files=["test/model/page_model_test.rb",
"test/model/widget_model_test.rb"], #verbose=true, #warning=false, #loader=:rake,
#ruby_opts=[]>
-------------------------------------
As you can see, The task finds the files, but it never actually runs them. How can I get it to run these files?
Using Rails 3.2.8 and ruby 1.9.3
So, two things you might want to check:
1) Make sure you're using the minitest-rails gem
It adds a lot of the test runner tasks we want and need.
https://github.com/blowmage/minitest-rails
2) The contents of your minitest_helper.rb file (a la spec_helper.rb)
You should have some kind of helper file that you're requiring in all your tests. Make sure it looks something like this:
ENV["RAILS_ENV"] = "test"
require File.expand_path('../../config/environment', __FILE__)
require "minitest/autorun"
require "minitest/rails"
class ActiveSupport::TestCase
fixtures :all
end
Now that you have that setup, you can run all the tests as follows:
bundle exec rake test
bundle exec rake minitest # alias for test
bundle exec rake minitest:models
# ... etc ...
Related
Trying to use a rake task to run only tests in the test/models directory. Using minitest.
I have a rake task that will run all test
require "rake/testtask"
Rake::TestTask.new(:test => "db:test:prepare") do |t|
t.libs << "test"
t.pattern = "test/**/*_test.rb"
end
task :default => :test
Then, running 'rake' hits the default and runs all tests. I want to write a second rake task that would only run tests in the models directory (test/models/).
I played around with this existing TestTask by simply changing
t.pattern = "test/**/*_test.rb"
to
t.pattern = "test/models/*_test.rb"
but, it seems to still run all the tests...not just models. Strange?
QUESTIONS
How can I accomplish this? How to I need to name a second TestTask that will run only models, and how do I tell rake to run that test instead of the default :test?
The pattern you are looking for is "test/models/**/*_test.rb". The "**" will match subdirectories as well.
If you are using minitest-rails then you have lots of tasks added for you. To run all Model tests run:
rake minitest:models
To see all the rake tasks creates for you, run:
rake -T
As usual, the answer was quite simple. Just took a bit of digging around. Make sure you have the following in your application.rb (inside the module).
config.generators do |g|
g.fixture_replacement :factory_girl # if your using factory_girl
g.test_framework :mini_test, :spec => true, :fixture => false
end
Then you have access to minitests built in commands. The one I was looking for is as simple
rake minitest:models
Booya!
https://github.com/memphis518/Garden-Dating-Service
The public repo above is a community coding project we're working on for Austin Community Gardens, and it's a fairly simple project so far, but for some reason rake db:seed doesn't work ("Don't know how to build task db:seed"), and when you run rake -T it reveals no rake tasks at all.
MongoID documentation says it provides most of the usual DB-related rake tasks - I can't figure out why they're not there.
I had the similar problem with Rails 3.X, although the mongoid Gem was included in my Gemfile. I could solve the problem by explicitly requiring the database.rake file from the mongoid gem. I added this 2 lines to my Rakefile:
spec = Gem::Specification.find_by_name 'mongoid'
load "#{spec.gem_dir}/lib/mongoid/railties/database.rake"
That works for me.
Had the exact same issue.
Realized I never added "mongoid" to my Gemfile. This fixes it:
gem 'mongoid'
It will add these rake tasks:
rake db:drop # Drops all the collections for the database for the current Rails.env
rake db:mongoid:create_indexes # Create the indexes defined on your mongoid models
rake db:mongoid:drop # Drops the database for the current Rails.env
rake db:mongoid:remove_indexes # Remove the indexes defined on your mongoid models without questions!
rake db:reseed # Delete data and seed
rake db:seed # Load the seed data from db/seeds.rb
rake db:setup # Create the database, and initialize with the seed data
I have the following spec_helper.rb file in my Rails 3.1 application. I am using Spork to load the environment faster for testing. All my tests worked prior to adding Spork to the mix. After adding spork, the test database was not getting properly cleared between test runs which threw off some of my expectations.
Following other instructions, I added database_cleaner to the mix with the code listed below; however, now, the development database is getting cleaned up as well as the test database. The ENV["RAILS_ENV"] call is returning test during this call.
Is there a way to explicitly limit the call for DatabaseCleaner.clean_with(:truncation) to only affect the test database?
require 'rubygems'
require 'spork'
Spork.prefork do
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
require 'shoulda/matchers/integrations/rspec'
require 'database_cleaner'
Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}
RSpec.configure do |config|
config.mock_with :mocha
config.formatter = 'documentation'
config.use_transactional_fixtures = true
config.before(:suite) do
DatabaseCleaner.strategy = :truncation
end
config.before(:each) do
DatabaseCleaner.start
end
config.after(:each) do
DatabaseCleaner.clean
end
end
end
Spork.each_run do
FactoryGirl.reload
end
Update: Here is my database.yml file
development:
adapter: sqlite3
database: db/development.sqlite3
pool: 5
timeout: 5000
test:
adapter: sqlite3
database: db/test.sqlite3
pool: 5
timeout: 5000
production:
adapter: sqlite3
database: db/production.sqlite3
pool: 5
timeout: 5000
Also, I have worked around the basic problem by moving the clean_with call into the before(:each) section, but this slows down the test runs significantly.
Have you tried to move ENV["RAILS_ENV"] ||= 'test' out of the Spork.prefork block?
Are you sure that Spork caused your DB got uncleaned? If you're using RSpec's transactional fixtures, the only thing that could lead to such thing is using factories within before(:all) block. You can clean up data in after(:all) block and get rid of DatabaseCleaner.
BTW, if you're using truncation strategy, there's no need to run DatabaseCleaner.start.
Is your RAILS_ENV explicitly set to "development"? If so, the default spec_helper will run the tests against the development DB. If you run a test from inside vim, or run rspec on the command-line, then it'll run the test against your development DB.
When I'm forced to use database_cleaner, I like to explicitly set RAILS_ENV to test in spec_helper to protect my development DB. Any time you're using something other than transactional fixtures, this is probably a good idea.
I note that you're using both transactional fixtures and database_cleaner. You don't need database_cleaner at all if your DB supports transactions. If you're using Mongo, or you are running capybara-webkit tests, then you'll need database_cleaner, and will want to disable transactional fixtures.
I am working through the Ruby on Rails 3 tutorial book and typed the following on the command line:
rake db:migrate
which produced the following warning.
WARNING: Global access to Rake DSL methods is deprecated. Please Include
... Rake::DSL into classes and modules which use the Rake DSL methods.
WARNING: DSL method DemoApp::Application#task called at /Users/imac/.rvm/gems/ruby-1.9.2-p180#rails3tutorial/gems/railties-3.0.7/lib/rails/application.rb:215:in `initialize_tasks'
I am not sure what to do about it or how to work with it. I don't know any other command for Rake.
How can I fix this problem?
Adding include Rake::DSL to the Rakefile before the applications load_tasks were called also worked for me.
So in the above user's case before the DemoApp::Application.load_tasks in the Rakefile.
I found this in Stack Overflow question Ruby on Rails and Rake problems: uninitialized constant Rake::DSL. It refers to a #DHH tweet.
Put the following in your Gemfile
gem "rake", "0.8.7"
You may see something like
rake aborted!
You have already activated Rake 0.9.1 ...
I still had a copy of Rake 0.9.1 in my directory so I deleted it.
You can "delete" Rake 0.9.1 by running the following command:
gem uninstall rake -v=0.9.1
If you have multiple versions of the gem installed, you'll be prompted to pick a version.
After 0.9.1 was cleaned out, I ran
bundle update rake
and was finally able to create my database files. I was using rake db:create, but it should work for rake db:migrate as well.
I hope it helps.
I was having the same problem on Windows with the installer. Ruby 1.9.2 and Rails 3.0.9.
Here is what I did:
bundle update rake
bundle show rake
After doing that I was running rake 0.9.2.
Then I updated the Rakefile in application root folder as follows:
require File.expand_path('../config/application', __FILE__)
require 'rake'
# If you named your application something other than SampleApp, change that below
module ::SampleApp
class Application
include Rake::DSL
end
end
module ::RakeFileUtils
extend Rake::FileUtilsExt
end
SampleApp::Application.load_tasks
As noted in the comment, make sure the name of your app is correct in the two appropriate lines above.
If you are seeing this on later versions of Rails (like 3.+) you may also want to verify that your environment is clean by using RVM http://beginrescueend.com/ and creating a specific ruby & gemset for your projects.
Use an .rvmrc file on a per-project basis, this will guarantee you aren't getting older system gems into your projects. Which has bitten me before.
This prevents having to monkey around with generated Rakefiles & such.
bundle exec rake db:migrate will solve your ruby version issues
It is pretty easy with the added generator of rspec-rails to set up RSpec for testing a Rails application. But how about adding RSpec for testing a gem in development?
I am not using jeweler or such tools. I just used Bundler (bundle gem my_gem) to setup the structure for the new gem and edit the *.gemspec manually.
I also added s.add_development_dependency "rspec", ">= 2.0.0" to gemspec and did a bundle install.
Is there some nice tutorial what to do next to get RSpec working?
I've updated this answer to match current best practices:
Bundler supports gem development perfectly. If you are creating a gem, the only thing you need to have in your Gemfile is the following:
source "https://rubygems.org"
gemspec
This tells Bundler to look inside your gemspec file for the dependencies when you run bundle install.
Next up, make sure that RSpec is a development dependency of your gem. Edit the gemspec so it reads:
spec.add_development_dependency "rspec"
Next, create spec/spec_helper.rb and add something like:
require 'bundler/setup'
Bundler.setup
require 'your_gem_name' # and any other gems you need
RSpec.configure do |config|
# some (optional) config here
end
The first two lines tell Bundler to load only the gems inside your gemspec. When you install your own gem on your own machine, this will force your specs to use your current code, not the version you have installed separately.
Create a spec, for example spec/foobar_spec.rb:
require 'spec_helper'
describe Foobar do
pending "write it"
end
Optional: add a .rspec file for default options and put it in your gem's root path:
--color
--format documentation
Finally: run the specs:
$ rspec spec/foobar_spec.rb
Iain's solution above works great!
If you also want a Rakefile, this is all you need:
require 'rspec/core/rake_task'
RSpec::Core::RakeTask.new(:spec)
# If you want to make this the default task
task default: :spec
Check the RDoc for RakeTask for various options that you can optionally pass into the task definition.
You can generate your new gem with rspec by running bundler gem --test=rspec my_gem. No additional Setup!
I always forget this. It's implemented here: https://github.com/bundler/bundler/blob/33d2f67d56fe8bf00b0189c26125d27527ef1516/lib/bundler/cli/gem.rb#L36
Here's a cheap and easy (though not officially recommended) way:
Make a dir in your gem's root called spec, put your specs in there. You probably already have rspec installed, but if you don't, just do a gem install rspec and forget Gemfiles and bundler.
Next, you'll make a spec, and you need to tell it where your app is, where your files are, and include the file you want to test (along with any dependencies it has):
# spec/awesome_gem/awesome.rb
APP_ROOT = File.expand_path(File.join(File.dirname(__FILE__), '..', '..'))
$: << File.join(APP_ROOT, 'lib/awesome_gem') # so rspec knows where your file could be
require 'some_file_in_the_above_dir' # this loads the class you want to test
describe AwesomeGem::Awesome do
before do
#dog = AwesomeGem::Awesome.new(name: 'woofer!')
end
it 'should have a name' do
#dog.name.should eq 'woofer!'
end
context '#lick_things' do
it 'should return the dog\'s name in a string' do
#dog.lick_things.should include 'woofer!:'
end
end
end
Open up Terminal and run rspec:
~/awesome_gem $ rspec
..
Finished in 0.56 seconds
2 examples, 0 failures
If you want some .rspec options love, go make a .rspec file and put it in your gem's root path. Mine looks like this:
# .rspec
--format documentation --color --debug --fail-fast
Easy, fast, neat!
I like this because you don't have to add any dependencies to your project at all, and the whole thing remains very fast. bundle exec slows things down a little, which is what you'd have to do to make sure you're using the same version of rspec all the time. That 0.56 seconds it took to run two tests was 99% taken up by the time it took my computer to load up rspec. Running hundreds of specs should be extremely fast. The only issue you could run into that I'm aware of is if you change versions of rspec and the new version isn't backwards compatible with some function you used in your test, you might have to re-write some tests.
This is nice if you are doing one-off specs or have some good reason to NOT include rspec in your gemspec, however it's not very good for enabling sharing or enforcing compatibility.