RSpec Tutorial: How to Configure Tests for Ruby / Rails Applications

Like many Ruby developers, the thought of having to test my code made me cringe. Not only was I clueless about software testing (i.e. regulations etc), I had never used RSpec before.

Fortunately, when I started using the system, things became much simpler.

RSpec is a test framework for Ruby and Rails. The system is extremely versatile and is intended to provide a simple framework for testing various functions within applications or plugins.

The system works as intuitively as possible, which means that each “test” is intended to deliver an expected result, allowing the developer to create an effective overview of the various functions of a system, as well as providing the ability to expand the scope. as necessary.

I’ll explain how it works in this post …

What is RSpec?

RSpec is an open source “gem” for Ruby, maintained by the Ruby core group.

The gem is available on Github, along with several others, most notably the “rspec-rails” gem (which was designed specifically for Rails).

Basically, the gem provides developers with a “framework” that can be called using the “rspec” command. This allows integration with CI suites such as TravisCI and CoverAlls.

The goal of having RSpec is to facilitate the creation of “unit tests” and “integration tests”, which are a basic element of the traditional software development process.

Having the ability to fully and extensively test a Ruby application, with a framework that is ubiquitous and extensible like the language itself, is one of the reasons the Ruby ecosystem is so highly regarded.

For the first time, without the need for expensive software or extensive IDE integration, developer teams can create software that works across all platforms and technology sets.

Therefore, when considering development in Ruby, the underlying value of RSpec cannot be overstated.

How does it work

RSpec must be initialized within a plugin / application.

It normally lives in the “spec” directory, but it can also be “test”.

To initialize RSpec, like most things in Ruby, it is best to follow the guidelines of what has already been developed, using the CLI command “rspec –init”.

Frame initialization fills the / spec folder with a “spec_helper.rb” file and populates it with a basic number of configuration options.

The “spec_helper.rb” file is at the core of all RSpec functions and is therefore extremely important.

Inside the file, all the configuration settings of an application are stored. This is where you need to include the various files needed to integrate the test suite into your script / application.

If you can run the “rspec –init” command (after adding “rspec” to your script’s Gemfile file), you’re ready to start the next step.

Configure

After configuring the “spec wizard”, the next step is to call the various elements of the integration suite.

This is a somewhat manual process and, especially if using Rails, it may involve a few steps outside of the “traditional” rulebook.

The most important step in this case is to set up a “dummy” Rails application.

I won’t go into too much detail, but it is necessary if you are creating a Rails gem (for example), and it is not something that can be done directly via rspec.

To do this, you basically need to create a fake “engine” from which you can extract the fictitious Rails application:

cd some_path_where_your_engine_IS_NOT 

rails plugin new YOUR_ENGINE_NAME –mountable –dummy-path = spec / dummy –skip-test-unit

mv YOUR_ENGINE_NAME/spec/dummy /real/path/to/YOUR_ENGINE_NAME/spec

rm -rf YOUR_ENGINE_NAME

This creates a / spec folder with a dummy Rails application, spec_helper.rb, and another file that is not important.

Doing the above ensures that the RSpec is configured correctly for Rails.

Again, without having the details about your specific application, if you need more information, you can email me (email in profile).

Testing

Once you’ve configured rspec, you need to order the tests.

This is a relatively simple process – it only takes some time to discover the various methods through which you can determine particular results.

The most important thing to note is that there are several different types of testing:

• Routing tests
• Controller tests
• Model tests
• Function tests
• See tests
• Mailer tests

There are two ways to make sure they work, either by creating folders inside your main / spec folder (/ spec / models or / spec / features, etc.) or just using the “type :: feature” option when declaring tests.

How this works becomes clearer when you consider how testing actually works.

Each “test” in RSpec must be wrapped in a “describe” block. Each file must be extracted from the RSpec class itself (RSpec.describe ___), but all the others can simply “describe”:

# spec / models / model_spec.rb

RSpec.describe Model make

describe “have email method” do

that {___}

end

end

The way you create your tests is with the “it” method, which is used to describe (in as much detail as possible) what each function is supposed to do.

Within the “it” block, you can use several different methods, ranging from “wait” to “should”, to provide the system with the ability to determine the particular results required from the script / application.

From here, you can create placeholders in context, using methods like “leave” to provide context for each test.

While you could write more tests, the bottom line is that this should give you a solid overview of what is required to make everything work. After this you just need to be able to write as many tests as you need.