If you’re a developer, then you have already performed a software test, whether you realize it or not. When you write a piece of software, to see if it's working, that's testing.
When you create a webform, then submit the form to see if it successfully adds the data to the database; that’s testing. When you submit the same form again, with the wrong input, to see if it rejects the form and tells the user there’s a problem, that’s also testing but manual testing.
Computers are great at performing repetitive tasks so when we talk about testing, we’re referring to code that can perform tests on other codes. RSpec is a framework that allows us to do that. The ‘R’ stands for Ruby and ‘Spec’ stands for Specification (detailed requirements that our code should meet). It’s often referred to as, “An executable example that tests whether a portion of code exhibits the expected behavior in a controlled context.”
In software testing, RSpec has a basic structure as follows;
- Given some context,
- When an event occurs,
- Then expect this outcome.
‘Given, When, Then’ is the basic structure of all tests.
For example, “Given a web form → When I fill out the form and submit, → Then I expect the data to add to the database successfully.”
Why Software Tests Are Important
Now, you may ask why software tests are important? Honestly, it would be difficult to have a career as a professional developer if you don’t write software tests.
Reasons Not To Test
As counter-intuitive as it sounds, it’s also essential to look at the reasons why you should not write software tests in order to weigh them against reasons we should write tests.
- Writing tests requires more time
- Time is money - that time can be better spent doing other things
Reasons To Test
- Find bugs — tests help make sure your code runs the way it should
- Stimulate critical thinking
- Covers edge cases
- Exposes poorly written code
- Boosts confidence when;
- Refactoring/improving code
- Adding features
- Upgrading related software
- Deploying code
- Even though it takes time, it will ultimately save development time
- In addition to saving time, it saves headaches
- Helps developers sleep well at night!
Now the question is, should we always test?
Small applications may not need testing, but testing becomes more critical as the complexity increases.
You don’t need Rails to use RSpec as RSpec will test any Ruby code. That said, Rails has made RSpec popular.
In this article, we’re going to take an in-depth look at how you can use RSpec with Ruby on Rails. RSpec with Ruby on Rails requires a different Ruby Gem, rspec-rails. For details and documentation on this, check out the rspec-rails GitHub page.
Including this gem in your application adds:
- The regular RSpec gem
- A library of helpers to make testing in rails much more comfortable
RSpec with Rails specific additions include: Generators, Helpers, and Matchers.
You should also note that the documentation page is a living document, therefore it’s possible changes may occur at the time you’re reading this article, so you should refer back to the documentation page from time to time. That said, the basics of the process should stay the same.
Setting up Our Project to use RSpec-Rails
Add Rspec-Rails to both the :development and :test groups of your app’s Gemfile.
Note: adding it to the :development group is not strictly necessary, but without it, generators and rake tasks must be preceded by RAILS_ENV=test.
Next, make sure you are in your project directory;
You will notice that Rails creates four files for you. To avoid confusion, you’ll have to choose one. It’s perfectly okay to delete the ‘test’ directory since we will be using RSpec for our testing.
You don’t need to worry too much about the difference between the rails_helper.rb and spec_helper.rb files as the difference is a bit of a technical point.
spec_helper.rb — things specific to RSpec and that do not require the Rails environment should be here.
rails_helper.rb — things that are about Rails or require Rails dependency should be here.
If you load rails_helpers, it loads spec_helpers at the same time.
Rails generators will generate placeholder files for your RSpec test. The standard rails generators will create appropriate spec files for you, as long as you have rspec-rails gem installed.
RSpec knows how to generate a number of different placeholder files. Below are the most frequently used generators:
The line of code above will also generate spec/models/user_spec.rb.
If you need to generate the spec file manually - perhaps because you are working on an existing application and model file has already been generated - the process is almost identical, you simply put rspec: in front of the type you want to create.
Let’s take a look inside the generated file. The first thing it does is require the rails_helper file. Remember, the rails_helper in-turn requires the spec_helper file.
`RSpec.describe` is just technically ensuring it’s scoped by RSpec, followed by a class name ‘User’ which allows it to implicitly set the subject for RSpec. The type allows RSpec to recognize what type of test this is. The ‘pending’ as the name implies it is a pending example allowing you to test run your specs.
Now that you have finished initializing your project to run with RSpec, the next thing is to ensure it actually does run.You’re likely already familiar with typing ‘rspec’ into your command prompt to fire it up. Don’t worry, that still works here in Rails.
First, let's look at the documentations way of running it:
Now, you’ve seen two methods in running specs, so let’s put it all together:
- bundle exec rspec
- rake spec
The first is more light-weight and I tend to use it more often. That said, ‘bundle exec rspec’ makes sure that all gems and things needed to run Rspec are loaded - it’s a kind of prefix to make sure RSpec runs in the right environment.
The last two, ‘rake spec’ and ‘rake’ require a little more setup. Sometimes you need to make sure the database setup is sufficient for you to run RSpec.
One of the most noticeable differences about working with RSpec on a basic Ruby project versus Ruby on Rails is the use of databases.
The default rails application provides you with three environments to work with;
- Development Environment
- Production Environment
- Test Environment
If you are new to testing, you may only be familiar with the first two. The idea behind all three is the same though, we can have unique configurations for development, production, and testing, yet keep them entirely separate.
For now, let’s focus on the database. You have three database configurations that correspond to each of these. That’s because you don’t want your development data to be mixed with your production data, nor your test data. We want to keep our test data independent from production, as well as development.
For example, if I’m developing a new feature and I have my database in a particular state then stop to run my test, I don’t want my test to stop what I have in development.
Therefore, the test database has its own database it can work with. I can read to it, write to it, and completely clear out its entire contents without affecting what's happening in development.
In order to use the test database, we need to prepare it to ensure it’s ready.
Remember, I mentioned earlier that running RSpec alone does not prepare the test database as the rake does. Although, from the word, go rails sets up your whole environment for you.
Calling rake spec or just rake will prepare your test database. Behind the scene, it calls `db:test:prepare`. To see what happens under the hood, add the trace option: rake spec --trace. The actual steps rake spec takes are;
- Drop the existing database: '$ rake db:drop RAILS_ENV=test'
- Create a new database: '$ rake db:create RAILS_ENV=test'
- Load in the schema file: '$ rake db:schema:load RAILS_ENV=test'
You can actually run these steps yourself if you don’t want `rake` to do it. Every time we run rails db:migrate it updates the schema file as well.
Note: if we load the schema file, we would have the same database as the development, with the right tables and columns, just without data.
You should save data to the test database only when it's necessary, as making database calls in your examples adds significant time to our test suite. A lot of the time, it’s really not needed - you don’t really need to save a user to the database to check if it’s valid.
An unsaved instance can do the job just as well, so you could have product.build or product.new. Test doubles can sometimes do the job or stubs. If your test suit is running slow, this probably could be the reason.
Each example in your test suite runs in a transaction, meaning that when an example finishes, database changes are rolled back — anything you do will be undone.
Looking at our spec/rails_helper.rb file, the line of code below makes this possible.
'config.use_transactional_examples = true' is an alias for fixtures. Personally, I think .._examples is clearer but at the moment the default uses fixtures.
To test out this idea, see the examples below.
No posts should still be in the database after the second example because of the transactional fixtures.
Note: examples do not necessarily run in order — there is a configuration option for running them randomly or, we could run each in isolation by specifying a line number from the command line. Refer to the running specs section of this article for more on this. Examples need to be kept atomic so that they can stand alone.
It is important to note that;
- Data modified by before(:example) is rolled back
- Data modified by before(:context) is not rolled back. This confuses a lot of people but is done to improve performance for an example group.
Say we want to have four users in our database and work with those throughout our examples. It makes sense to leave them there to give us a performance boost. You do not want to leave them there after our example group is done though. Use after(:context) to revert the modified data.
A good example of before(:example) would be:
By now, you should have an in-depth understanding of rails-specs. In the next article, we will go over how to work with rails specs in detail. I also want to give credit to Kevin Skoglund as a lot of the knowledge and insights in this article are from his tutorials on RSpec.
To learn more about Microverse, and joining our supportive community of remote software developers, get started below!