This is the 14th Testing Tuesday episode. Every week we will share our insights and opinions on the software testing space. Drop by every Tuesday to learn more! Last week we found out how mocking with Bogus can replace your integration tests in some situations.
Set up RSpec for Ruby applications
For all Ruby applications you can use the rspec gem. The gem is a collection of 3 other gems:
You can also include one or more of these gems separately. For instance, if you want to use Bogus for mocking, like we did in last week’s episode, you can just add rspec-core and rspec-expectations to your Gemfile, because you don’t need rspec-mocks.
If you run
rspec from your project’s root directory without any argument, it will expect your specs to be in the
./spec directory and your classes to be in the
./lib directory. Although you can work around this assumption, I recommend you to stick to them: They are applied in almost all Ruby projects.
Set up RSpec for Rails applications
These rspec gem will work for every Ruby application you create, so you could also use it with your Rails applications. However, there is a more convenient option: The rspec-rails gem is the easiest way of setting up RSpec for Rails. It will provide you with convenient generators that get called when you generate resources like models or controllers. Watch the screencast to see it in action!
Up next Testing Tuesday: How to set up Cucumber
Next week we’ll set up our Ruby and Rails applications with Cucumber. In the meantime check out our other episodes on RSpec. You can find a list of them below in the “Further info” section.
- Testing Tuesday #10: Designing code with RSpec
- Testing Tuesday #9: Stubbing and Mocking with RSpec
- Testing Tuesday #8: Behavior-Driven Integration and Unit Testing
- Testing Tuesday #2: From Test-Driven Development to Behavior-Driven Development
Setting up RSpec
Ahoy and welcome! My name is Clemens Helm and you’re watching Codeship Testing Tuesday #14. Recently we’ve talked a lot about Behavior-Driven development with RSpec and Cucumber, but I didn’t show you how to integrate these tools into your Ruby applications. That’s why we’ll look into setting up RSpec in this episode.
We’re gonna set up one standalone Ruby application and one Rails application, because there are a few differences in the setup. Let’s get started with the standalone application first:
We create an empty directory “ruby-app” for our application
cd ruby-app. In the directory we create a Gemfile and add
as dependency. When we install the
bundle, we see that 3 additional RSpec gems got installed:
- rspec-expectations and
rspec gem is only a collection of these 3 gems, so feel free to include them separately. For instance, if you want to use Bogus for mocking, like we did in last week’s episode, you can just add
rspec-expectations to your Gemfile, because you don’t need
When we run
rspec now, it complains that there is no
spec folder in our project. Let’s create it and run
rspec again. It finishes without running any examples. Now let’s add an example to our application:
# spec/app_spec.rb describe App do it "should launch" do App.launch.should be_true end end
RSpec tells us
uninitialized constant App. Let’s create the app class. By default, application code lives in the
lib directory. So let’s create this directory
mkdir lib and put a class “App” into file
But RSpec still complains that there is no constant
App. We need to tell the spec file where to look for our app class. Adding the line
require 'app' lets RSpec find our source file, so now we get a different error message that the method
launch does not exist. But wait a minute? Why did RSpec find our
app.rb file? It’s in the
lib directory, so how did the
require statement know where to look for it?
The answer is a Ruby global variable that contains the load paths for files. If we add the line
puts $: to our spec file and run rspec again, we see all the directories that ruby checks when requiring a file. At the very top there is our
spec directory and our
lib directory. RSpec added these two directories, because it’s the convention to put code in there.
But back to our error message: We still need to add a class method
launch to the app. Let’s remove this debug output and add the method.
class App def self.launch end end
rspec And our launch method should be true
class App def self.launch true end end
And now we’ve got a working test suite with RSpec! These few steps will work for every Ruby application you create, so you could also use it with your Rails applications.
However, there is a more convenient option: The
rspec-rails gem is the easiest way of setting up RSpec for Rails. Let’s create a rails application first:
rails new rspec-rails-app
rspec-rails to our Gemfile. We only need it for our test and development environment. Why do we need it for development? I will get back to this in a minute.
rspec-rails using bundler:
rspec-rails provides us with an installation generator.
rails generate rspec:install
This creates our spec directory with a
spec_helper.rb file that contains the RSpec configuration for our app. There is also another file
.rspec where we can insert default options for the RSpec runner. By default, it contains the
--color option which creates colorful output on the terminal, but we could also choose a different formatter for RSpec results or other options in here.
Now that we’re set up, let’s run RSpec. Usually you’ll want to run your examples with
bundle exec rspec. This will load all the dependencies from your Gemfile, so they are available in your examples. It’s cumbersome to write
bundle exec all the time though. That’s why in Rails 4 we can create a binstub for it. Running
bundle binstubs rspec-core
creates such a binstub in the
ls bin mate bin/binstub
So this file will set up our bundle for us and run RSpec. Let’s give it a try:
bin/rspec. It works!
rspec-rails has several advantages. For example, we don’t need to manually require our application files. Another advantage is that RSpec automatically creates spec files for us. Let’s create a model
rails generate model user username:string
RSpec created a spec file for our user model automatically. And when we run rspec now
bin/rspec, it will remind us first to run our migrations, because we added a new database model
rake db:migrate RAILS_ENV=test and then
bin/rspec we’ve got a pending example that reminds us to add some examples for our user. Pretty neat!
So now that you know how to set up RSpec, there’s no excuse anymore not to use it! If you haven’t already, check out our other episodes on RSpec. I’ll link to them in the blog post. Next week I’ll show you how to set up Cucumber with your Ruby applications. Then you should be completely settled for your Behavior-Driven development workflow. See you next week, keep it real and always stay shipping!