Now that your RSpec environment is all set up, it’s time to start writing some actual tests. Let’s start with integrations tests, which tests how different components (models, controllers etc.) interact with one another.
Create the Integration Folder
To start, make future you and any team members really happy by creating an integration folder, within the spec folder, to hold your tests. You can do this from the root folder in the terminal with mkdir spec/integration.
Next, in your integration folder, create the file where you’ll write your test. Convention dictates that the filename should consist of what your testing followed by spec, separated by underscores. Here are some examples:
It’s up to you how to describe the test but you want to makes sure that it makes sense to both you and anyone else that might be looking at your test, and it must end in with _spec, that’s the only way RSpec will know it’s a test.
To run integration tests, we’ll need to require an additional gem in our :test group, Capybara. What’s Capybara you ask? In addition to being an African rodent, Capybara allows us to test functionalities that require use of the webpage. This includes things like filling in forms and clicking on buttons. Basically it allows you to simulate how users actually use the webpage so that you can test desired outcomes.
So go ahead and update your Gemfile and bundle:
group :test, :development do gem 'rspec-rails' gem 'capybara' end
Now back in the in the integration test file you created, you’ll need to start by requiring spec_helper (remember that file that got created when you generated rspec). At the top of the file add:
Red Green Refactor
Writing TDD means you should most likely follow a “Red, Green, Refactor” pattern. What this means is you should:
- Write a test- This will fail without any code, displaying red in your terminal.
- Write the passing code – this should be the bare minimum needed to make it pass.
- Go back and refactor that code for optimization.
Make sure you run the test before starting on the code. It’s a common mistake to write a test that’s not actually testing what you think it is. False greens, or tests that are passing before the actual code is written, is an easy way to spot these inaccurate tests.
Write Your First Test
Starting small, say the first thing you want to do is add a title to the homepage. Here’s the test to make sure that the title is there:
require 'spec_helper' describe "Home Page" do context "display content" do it "should have a title" do visit root_path expect(page).to have_content "Welcome to My Page" end end end
You might see alternatives to the describe/context combination. For instance some developers use specification/feature, a combo of the two, or just a describe. It’s up to you, but the main idea is to make sure you’re making it really clear what you’re testing, and you’ll want to pick one way and stick to it throughout the remainder of the tests for readability purposes.
In the example above I’m using:
- describe to state the high level of what I’m testing (“Home Page”)
- context to drill down on what about the Home Page I’m testing (“display context”). You might notice that the to phrases makes a comprehensible phrase “Home page display context”. While not mandatory, a good way to make sure your labeling things well.
- it is used to spell out the expectation, (“should have a title”)
Great, so we’ve set up our 3 statements (don’t forget your dos and ends) next we put capybara to work by taking a look at the page and seeing if it contains the title we will eventually create.
In addition to visit, Capybara let’s you do a large host of actions include fill_in (great for form and textarea tests) click_link and click_on. Check out the docs for a complete list.
Run Your Test
To run your test, you’ll need to head back to the terminal and type out rspec and the file path to the test, here’s an example:
You’ll get a failure that looks like this:
Notice that they’ve concatenated the 3 statements to make one test title “Home Page display content should have a title”. This goes back to what I was saying about being careful about how you describe your tests. It may be obvious when you’ve only written one test which test it’s referring to, as you app and test folders grow, you’ll appreciate being able to quickly pinpoint what tests are failing.
Another helpful aspect of the RSpec printout is the error message which tells us why the test failed “unidentified local variable or method ‘root path’”. So the test to the line that read “visit root_path” tried to do and couldn’t find out… probably because we haven’t made it yet.
To get this code to pass you’d have to go create you path and and add text to the corresponding view page to match the string you put in your test. Then head back to the terminal and rerun your test, you should see ALL GREENS!!!