2 Examples of Ruby testing with Rspec

In this article, we are going to study two testing cases.

There are a lot of Ruby testing frameworks out there. But the principles learned here can be useful to hasten the learning of other frameworks.

The code we are going to test is pretty simple so you can focus on Rspec rather than the complexity of the code to test.

Let us begin:

Simple Sum test

Take a look at this file:

The above file meets to functions:

1)The function to test:

2) The rest of the code is used by the Rspec framework.

The describe block has two examples. The first example checks that 5 plus 9 equals 14 and the second example that 5 plus 9 does not equal to 13

Passing example

Line 7 describes what we are going to do in this example. This will help us find the offending example when we write a lot of them.

Line 8 to 10 works like this:

expect([function to test]).to be([expected result])

or

expect(
  [function to test]
).to be([expected result])

or

expect(
  [function to test]
).to(be([expected result]))

or

expect(
  [function to test]
).to(
  be(
    [expected result]
  )
)

One example can have many expect().to be() lines in it.

This is another example but with a NOT condition. Take a look at line 16: ‘not_to’

A passing example with a NOT condition

Now run:

rspec [filename]_spec.rb

‘filename’ is the name of the test file that in this case contains the name of the code to test. This situation is an exception. In most situations we require the code to test through a function. You’ll see how to do this in the next example.

The necessity of the suffix ‘_spec’ is for testing many files. When you run the command

rpsec [folder_name]

Rspec discriminates files inside the folder having ‘_spec.rb’ suffix. It runs those files excluding the ones that don’t have that suffix. But for this to happen, we need to configure other things and that is out of the scope of this article.

After running the above command everything should work ok and send an output like this.

Passing test console output

The first line has two green dots. Each dot represents a passing test. When a test fails it shows a red ‘F’. We will see this happening by deliberately making the test fail by editing the code of the file like this:

Run this command again:

rspec [filename]_spec.rb

Failing test console output output

In the first line of the output we see a red F and a green dot. That symbolizes one failing test and one passing test respectively.

Check output ‘expected’ and ‘got’ and see how it makes sense. The part saying ‘Compared using equals?…’ is out of the scope of this article. That’s a concept for another article.

Pretty simple. Right? Let us try a more complicated example:

Calculator Test

Take a look at this file:

calculator.rb: A calculator with the 4 most famous operations

This file above defines a calculator with 4 operations:

addition, subtraction, multiplication, and division

Division operation in detail

The division operation contains three use cases: infinity, positive infinity and indeterminate.

The test file:

In the above file we test each part of code with many examples. We do so by dedicating each ‘describe’ to test an operation in the calculator.rb file.

In the real world testing each section of the code several times is not feasible, is not economic. A good practice when starting a project is to test only critical portions of code one or several times. After this, is good to leave some portions untested and move on to other tasks.

The are some cases when it is convenient to test 100% of the code in a file. When a file has:

- given a lot of problems during development.

- portions of code frequently requested from other files

For the sake of simplicity in this article, consider the line 5 an equivalent to

calc = Calculator.new()

Run:

rspec functions_spec.rb

You should see this output:

rspec command output

Here we see 12 green dots. Each for each passing test.

Some considerations for writing tests:

One good practice is to brainstorm ideas by enunciating the tests. Only enunciating them without implementing. We call that concept ‘Pending Example’ and here you can dive more into it:

Pending Examples

This is good when you have a testing idea and you have the anxiety of not forgetting it. In this case, you enunciate it in the testing files and then free your mind to do other tasks.

Sometimes processing all cases take too long and you don’t want to wait for every case to pass. Or sometimes one case fails and you just want to focus on that case. In these cases, something that will help you is the concept of ‘Inclusion Filters’. Check this page to dive into that. Also, there is the mirror concept of Exclusion Filters.

Conclusion

Here we have seen two test approaches, one simple, and one more complex. To learn more about Rspec and how to install it see this:

The Odin Project

Official Documentation

Tutorials Point

Test-driven development has helped me write better code and saved me a lot of headaches. If you are still skeptical about the benefits of TDD I recommend you this article:

TDD Changed My Life by Eric Elliot

Follow me on Twitter!