https://fast.wistia.com/embed/medias/32mkqcbm0u.jsonphttps://fast.wistia.com/assets/external/E-v1.js

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.

For all Ruby applications you can use the rspec gem. The gem is a collection of 3 other gems:

• rspec-core

• rspec-expectations and

• rspec-mocks

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.

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

• rspec

• rspec-rails

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

gem "rspec"

as dependency. When we install the bundle, we see that 3 additional RSpec gems got installed:

1. rspec-core

2. rspec-expectations and

3. rspec-mocks

The 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-core and rspec-expectations to your Gemfile, because you don't need rspec-mocks.

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 app.rb inside. mate lib/app.rb

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

Let's add 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.

Let's install rspec-rails using bundler:

bundle

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 bin directory.

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!

Using 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 User:

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!