2. Setting up RSpec

TasteDrivenDishes is currently functioning. At least we think it’s functioning. Our only proof of that is we clicked through the links, made a few fake accounts and recipes, and added and edited data through the web browser.

Ship it, right?

Of course, this approach doesn’t scale as we add features. Before we go any further, let’s pause feature development and add an automated test suite, with RSpec at its core. Over the remainder of this book, we’ll add coverage to TasteDrivenDishes, starting with RSpec, and adding other testing libraries as necessary to round out the suite.

Once upon a time, it took considerable effort to get RSpec and Rails to work together. That’s not the case anymore, but we’ll still need to install a few things and tweak some configurations before we start adding specs.

In this chapter, we’ll complete the following tasks:

• We’ll start by using Bundler to install RSpec.
• Next, we’ll check for a test database and install one, if necessary.
• Finally, we’ll configure RSpec to run the test suite!

Dependencies

Since RSpec isn’t included in a default Rails application, we’ll need to take a moment to install it. We’ll use Bundler to add the dependency. If you don’t already have a terminal command line open in the application, open one now. Then, at the command line prompt, type:

bundle add rspec-rails --version "~> 6.1.2" --group "development, test"

Note that we’re only installing RSpec for use in the application’s development and test environments. It won’t be installed when deploying the application to production. We’ve also locked the version so that Bundler will install any version of the rspec-rails gem equal to or greater than 6.1.2, but not 6.2 or newer.

Technically, we’re installing the rspec-rails library, which includes rspec-core and a few other standalone gems. If you were using RSpec to test a a non-Rails Ruby application, you might install these gems individually. rspec-rails packages them together into one convenient installation, along with some Rails-specific conveniences that we’ll begin talking about soon.

Our application now has the first building block necessary to establish a solid test suite. Next up: Creating our test database.

Test database

For the purposes of teaching you about RSpec without much extra overhead, TasteDrivenDishes uses SQLite for its database backend.

If you’re adding specs to an existing Rails application, there’s a chance you’ve already got a test database on your computer. If not, here’s how to add one.

Open the file config/database.yml to see which databases your application is ready to talk to. If you haven’t made any changes to the file, you should see something like the following:

1 test:
2   <<: *default
3   database: db/test.sqlite3

Or this if you’re using MySQL or PostgreSQL:

1 test:
2   <<: *default
3   database: recipes_test

If not, add the necessary code to config/database.yml now, replacing recipes_test with the appropriate name for your application.

To ensure there’s a database to talk to, run the following rake task:

$ bin/rails db:create:all

If you didn’t yet have a test database, you do now. If you already had one, the rails task politely informs you that the database already exists–no need to worry about accidentally deleting a previous database. Now let’s configure RSpec itself.

RSpec configuration

Now we can add a spec folder to our application and add some basic RSpec configuration. We’ll install RSpec with the following command line directive:

$ bin/rails generate rspec:install

And the generator reports:

Running via Spring preloader in process 28211
      create  .rspec
      create  spec
      create  spec/spec_helper.rb
      create  spec/rails_helper.rb

We’ve now got a configuration file for RSpec (.rspec), a directory for our spec files as we create them (spec), and two helper files where we’ll eventually customize how RSpec will interact with our code (spec/spec_helper.rb and spec/rails_helper.rb). These last two files include lots of comments to explain what each customization provides. You don’t need to read through them right now, but as RSpec becomes a regular part of your Rails toolkit, I strongly recommend reading through them and experimenting with different settings. That’s the best way to understand what they do.

Next–and this is optional–I like to change RSpec’s output from the default format to the easy-to-read documentation format. This makes it easier to see which specs are passing and which are failing as your suite runs. It also provides an attractive outline of your specs for–you guessed it–documentation purposes. Open the .rspec file that was just created, and edit it to look like this:

--require spec_helper
--format documentation

Alternatively, you can also add the --warnings flag to this file, too. When warnings are enabled, RSpec’s output will include any and all warnings thrown by your application and gems it uses. This can be useful when developing a real application–always pay attention to deprecation warnings thrown by your tests–but for the purpose of learning to test, I recommend shutting it off and reducing the chatter in your test output. You can always add it back later.

The rspec binstub

Next, let’s install a binstub for the RSpec test runner, just to save ourselves from a bit of typing. We’ll be running the test suite a lot! On your command line, generate the binstub:

1 bundle binstubs rspec-core

This will create an rspec executable, inside the application’s bin directory. If you don’t want to install the binstub for whatever reason, you can skip this section–just remember to use the bundle exec rspec command wherever I use bin/rspec throughout the book.

Try it out!

We don’t have any tests yet, but we can still check to see if RSpec is properly installed in the app. Fire it up, using that binstub we just created:

$ bin/rspec

If everything’s installed, you should see output something like:

    No examples found.

    Finished in 0.00015 seconds (files took 0.0484 seconds to load)
    0 examples, 0 failures

If your output looks different, go back and make sure you’ve followed the steps outlined above.

Summary

In this chapter, we added RSpec as a dependency to the application’s development and test environments, and configured a test-only database for our tests to talk to. We also added default configuration files for RSpec.

Now we’re ready to write some tests! In the next chapter, we’ll start testing the application’s functionality, starting with its model layer.

Exercises

• If you’ve got an existing Rails application that needs a test coverage, feel free to begin building a test suite now, following the steps we took to install and configure RSpec in TasteDrivenDishes.
• Or, try creating a new Rails app from scratch! It doesn’t need to be fancy or even unique. A simple to-do list or blog is always great for learning, or perhaps a tool to help track items in your favorite collection. Be as creative as you’d like!
• Or, perhaps you have ideas for features you’d add to TasteDrivenDishes! If that’s the case, take a little time to build them out. They don’t need to be fancy or pretty, but you may want to do this work in a separate copy of the code to avoid conflicts in future chapters.

Whichever path you choose, don’t worry about tests yet. If you took the existing Rails app or scratch app route, install and configure RSpec in it now. Make sure you’ve installed the necessary gems and configured for the application. Ensure bin/rspec successfully runs.