Set up RSpec to test a gem (not Rails) - testing

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.

Related

Rails 3.2.11 performance testing issue: Don't know how to build task 'test:benchmark'

I'm following this railscast on performance testing, but I'm immediately running into an issue.
My app is rails 3.2.11, so according to the railscast it should include performance testing, but I don't have a folder called 'test' at all. When I run 'rails generate performance_test homepage' nothing happens or is generated. So I created one manually (to exactly match the railscast source code), but when I run rake test:benchmark I get the error
Don't know how to build task 'test:benchmark'
If I add the 'rails-perftest' gem to my gemfile and run bundle, then again try to generate a performance_test nothing happens, and when I then run rake test:benchmark, it throws a different error of
uninitialized constant Rails::SubTestTask
I've been sure to include the following dependencies in my gem file:
gem 'ruby-prof', group: :test
gem 'test-unit', group: :test
Could anyone help advise me what I'm doing wrong? Thanks!
I am not 100% certain on this, but I am guessing that you might not have your application.rb file configured accordingly. Also check your Gemfile.lock file and run the command bundle install because it could also be something funky going on with your Gems and dependencies.

How to set sinatra-authentication to use erb instead of haml?

I'm trying to set up the sinatra-authentication gem in a simple sinatra app, and running into an issue where sinatra can't find the correct views. I understand that sinatra-authentication uses haml by default, but I'm using erb in this app.
This in mind, I found in the sinatra-authenticaiton docs that there is a setting which allows you to change the template engine, by adding the following to your app file:
configure do
set :template_engine, :erb # for example
end
I've added this to my app.rb file, and sinatra is still looking for the signup.haml when I try to hit the /signup route in my app.
A couple of notes:
I've included the gem in my Gemfile, and successfuly run a bundle install on my app.
source 'https://rubygems.org'
gem 'sinatra'
gem 'data_mapper'
gem 'pg'
gem 'dm-postgres-adapter'
gem 'sinatra-authentication'
I saw something in the documentation that suggested that I may need to specify the location of my view files, so I added the following to my configuration block.
set :sinatra_authentication_view_path, Pathname(__FILE__).dirname.expand_path + "views/"
**I think I've required the gem accurately in my app file by adding
require "sinatra-authentication"
use Rack::Session::Cookie, :secret => 'mys3cr3tk3y'
This gist is a current representation of my app.rb file in the root of my sinatra app. https://gist.github.com/rriggin/5378641#file-gistfile1-txt
Here is a screenshot of the error sinatra throws: http://cl.ly/image/0y041t0K3u3O
When I run the app locally, a 'dm-users' table is created in my local db as expected.
Is there another configuration setting that I'm missing in order to get sinatra-authentication to properly look for the erb templates rather than haml files. Any help would be greatly appreciated.
Thanks
The specs don't test that the template_engine setting works, and looking at the way the setting is called, I believe it's not correct, i.e.
send settings.template_engine, get_view_as_string("index.#{settings.template_engine}"), :layout => use_layout?
might better work as:
send app.settings.template_engine, get_view_as_string("index.#{app.settings.template_engine}"), :layout => use_layout?
that's what I reckon. If you fork the project, change the line and add it to your Gemfile and it works then consider writing a quick spec for it and you'll have improved the mainline of that project as well as fixed your problem.

How to get the error log from SASS when using the rails asset pipeline?

I've got 3 Rails 3.2 applications using the gem jquery-ui-themes. jquery-ui-themes uses scss for the image-path helper.
It works great on two of my applications, but the 3rd doesn't seem to compile the scss files in either development or production modes.
IOW, it sends this to the browser
background: #fcfdfd url(image-path("jquery-ui/redmond/ui-bg_inset-hard_100_fcfdfd_1x100.png")) 50% bottom repeat-x;
whereas the two working apps properly send
background: #fcfdfd url("/assets/jquery-ui/redmond/ui-bg_inset-hard_100_fcfdfd_1x100.png") 50% bottom repeat-x;
I've spent many hours trying to make the app that's broken as similar to possible to the two working apps as I can, but it's still failing.
My theory is that SASS is choking on something previous to redmond.css.scss. If so, there should be an error logged somewhere. Where do I find the error output from SASS?
Update:
I introduced a deliberate error into redmond.css.scss and I got a proper error dump. So I know that I'm correctly clearing the cache and actually running sass. Now to figure out why it's ignoring the image-path directives.
If you're looking for the answer to the question in the title, the answer is "the same way you get any other errors: they're in your log". To get a full backtrace, just point your browser at the asset: ie http://localhost:3000/assets/jquery-ui/redmond.css in my case.
Make sure you clear all your caches: rm -rf .sass-cache/ && rm -rf public/assets && rake tmp:cache:clear, as well as using ctrl-shift-r in your browser.
If you're looking for the answer for my real problem (image-path not working), make sure you have the proper Bundler.require line in your application.rb. The old Rails 3.0 doesn't work.
replace:
# If you have a Gemfile, require the gems listed there, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(:default, Rails.env) if defined?(Bundler)
with:
if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
# Bundler.require(:default, :assets, Rails.env)
end

Global access to Rake DSL methods is deprecated

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

Get Cucumber to use the test environment in Sinatra

This seems right, but doesn't seem to work.
env.rb:
class MyWorld
set :environment, :test
end
app.rb:
configure :development do
DataMapper::setup(:default, "sqlite3://development.sqlite3")
end
configure :test do
DataMapper::setup(:default, "sqlite3://test.sqlite3")
end
It keeps using the development environment. Am I missing something, or am I doing it wrong?
Put this at the top of env.rb, and things work perfectly:
env.rb
ENV['RACK_ENV'] = 'test'
Alternatively, this will do the same without having to edit any files:
$ RACK_ENV=test cucumber features
You might want to look into the cucumber-sinatra gem. It has options to autogenerate a minimal amount of code (including your Sinatra app & rackup file). It should provide the correct syntax for getting cucumber scripts to run in test configuration.