RSpec - Writing Test Code In Ruby (3/3)

p.s. This is a series of articles and each article builds off another. I suggest starting at Part 1.

Mini Series

• TestUnit - Writing Test Code In Ruby (1/3)
• MiniTest - Writing Test Code In Ruby (2/3)
• RSpec - Writing Test Code In Ruby (3/3)

RSpec

RSpec is purely a BDD test framework.
In RSpec tests are called specs.
Spec files are must end with _spec.rb

RSpec is different from MiniTest in that its DSL provides even more magic to make specs more human readable.

RSpec also has richer extensions designed for BDD.

RSpec also integrates seamlessly with Cucumber user acceptance
framework.

Install RSpec Via Bundler

Our Gemfile will be the same as the previous lecture with the exception
we will swap out minitest for rspec

# Gemfile
source 'https://rubygems.org'

git_source(:github) do |repo_name|
  repo_name = "#{repo_name}/#{repo_name}" unless repo_name.include?("/")
  "https://github.com/#{repo_name}.git"
end

gem 'rspec'

Then we'll need to install rspec

bundle install

Intializing RSpec

Rspec makes it easy for us to set up a conventional directory structure.
This will be important to keep our spec files all in one place.

We can initialize RSpec by running the following:

rspec --init

Then you should see it create the following:

create   .rspec
create   spec/spec_helper.rb

RSpec will create an .rspec file.
The .rspec file allows us to include or exclude different directories
or files to be run.

It will also create a spec directory to house all our spec files.

spec_helper.rb is a file to change the configuration of how we want
RSpec to behave.

Creating our HelloSpec with RSpec

We will need to create our hello_spec.rb and place it within the spec directory and we'll create our file and compare the difference between MiniSpec

# spec/hello_spec.rb
require_relative '../hello'

RSpec.describe Hello do
  context "#world" do
    it { expect(Hello.world).to eql 'world' }
  end
end

No require necessary

You will notice that we did not need to require RSpec.
RSpec automatically includes itself when you have spec files
within the spec directory. This behaviour is what developers would
be called magic.

Change of directory

We had to change the path to require our file since it now is up one
directory. ../ means go up one directory where ./ means within the
current directory

require_relative '../hello'

Specifying RSpec

We need to place RSpec. in front of describe.
This is not always the case where if we use Rails we can exclude RSpec..

RSpec.describe Hello do

Matchers and Human Readability

Let us compare the difference in matchers.

# MiniTest
it "should return world" do
  Hello.world.must_equal 'world'
end

# RSpec
it { expect(Hello.world).to eql 'world' }

You can see that the DSL of Rspec allows for more
concise ways of writing specs.

Running RSpec

RSpec knows where it expects your spec files to be so you can simply run

rspec

Thoughts on RSpec

RSpec is purely BBD
It can produce more concise DSL syntax
It uses more ruby magic which could lead to confusion.
It has strong conventions for organizing your files which also reduces
the amount of manual configuration.
RSpec at scale is much slower that MiniTest and TestUnit.

Code

References

https://rspec.info/

Comments

[Andrew Brown 🇨🇦]

Wouldn't you want to mock the third-party api endpoints within your tests?
I'm guessing you're thinking to use HTTParty to test live endpoints.

Are these API endpoints external or the app's endpoints?
Also another question is this Rails or you rolling your own testing solution?

[Andrew Brown 🇨🇦]

I think there is only hard asserts in RSpec.

What do you want to build with HTTParty?
The "automation" word there is throwing me off.
I've used HTTParty when I need to make a gem for API for a third party service eg. Yelp.
Are you using it for this?

[Travis Simpson]

What a wild time, trying to learn some Ruby and get into unit tests, look up articles on it, thoroughly enjoy and find this section useful. Notice "ExamPro" on the side and think "this is familiar..." I know this is old now but great to run back into some of your work Andrew!

[Andrew Brown 🇨🇦]

Thanks Travis! and hello again!

[Taras Oliynyk]

I liked all the articles, Andrew. Nice job! Every reader can get a short and concise understanding of each testing tool.

[Andrew Brown 🇨🇦]

I have more of these articles already written. but the visibility here for serialized content is not effective on DEV.to so considering releasing the additional content in another format possibly like theodinproject or how freecodecamp has a free curriculum.

This content goes all the way to showing out test a Ruby on Rails app and is my training handbook for people to work on my projects.

I would love to publish full free courses on DEV.to but don't have the time to add the features into the dev.to codebase and get them successfully merged to do so that would help it make sense.

[aRtoo]

Nice article sir. Hope you can add more real scenarios like testing controllers, models, and integration testing.

[Andrew Brown 🇨🇦]

If it is for the purpose of testing API endpoints, have you considered using Postman?

Or you want to automate it within your CI/CD pipeline?

[Olayinka Zadat O]

This was really helpful