Run Test Suite

Goals

• Set up the application for RSpec
• Run the local test suite

Lesson Setup

If you are continuing immediately from a previous exercise and the application is already running at http://localhost:3000, you're good to go; otherwise, restart the services that run your application:

Open two separate terminal windows or tabs: in the first, start Fedora, Solr, and your Rails server. In the second, open a Bash prompt to your rails server. See Common (Docker) Tasks for detailed instructions. When you're using Docker, all the commands below should be entered at the root@...# prompt in the Bash window instead of your local $ prompt. For the exercises, you should always have two terminal session running: one where your development and test servers are running; another has your main Bash window where you will run the lesson commands from the # prompt.

Check out the working branch

git checkout ci_setup If you're interested in the changes made to set up for this lesson from the state of the repository at the end of the "Hyrax Stack Walkthrough" lesson, see this commit.

NOTE: If you make experimental changes and want to get back to the minimal code state necessary to run this lesson, you reset your git working tree by running:
git reset --hard origin/ci_setup

LESSON: Set up RSpec

In this workshop, we're going to follow the practices recommended by Test Driven Development. That means we're going to be writing automated tests for each new feature we develop. In order to do that, we first need to set up an automated test suite.

The Samvera community tends to use RSpec for testing rails applications. When we generated a new Hyrax work type, we also auto-generated some RSpec tests for that new work type. However, we need to do some setup before those tests will run.

1. Ensure the RSpec-required gems are included in your Gemfile. The file is found in the root of your Rails application. Look for a block beginning with group :development, :test do. Note that rspec-rails and capybara are installed. These are the main testing libraries we'll be working with.

2. Setup database cleanup for Fedora/Solr and the relational database: Open spec/rails_helper.rb. Around line 69 notice the cleanup tasks that we've added to this application. Why do we need to clean Fedora and our database before each test suite?

3. Look at the rake ci task. Look at the file in lib/tasks/ci.rake. What is it doing? What does CI mean?

Run the test suite

Option One: keep test servers running in the background

We'll use this strategy when using Docker and already took care of it in the lesson setup. This is useful if you want to run single tests. It's also a good pattern if you want to run tests often and don't want the overhead of starting Solr and Fedora each time

Option Two: start servers as needed

This is useful with continuous integration (CI) services like TravisCI. We won't be doing this one in class. We are instead relying on docker to keep test instances of solr and fedora running for us.

Run Some Tests

1. In your main terminal session, run your test suite
   rspec spec
2. You can run just the tests (examples) in a single spec file like this
   rspec spec/models/image_spec.rb
3. You can run a single test (example) like this
   rspec spec/models/image_spec.rb:6

For discussion

• What does TDD stand for?
• What are some of the reasons for using TDD?
• What is an RSpec "example"
• Compare the structure of our /spec directory to our /app directory
• What does "pending" mean in the context of our test suite?
• What does that Randomized with seed line mean? What are we randomizing and why?