Red and Green aren’t just colours for Christmas, they are also the colours I see when I type “learn” and hit the enter button in my terminal when I’m trying to pass one of the labs in Learn.co. While I feel a sense of relief when I see all my tests are in green text, showing that they all passed and that my code works, the real fun is in feeling like a detective, solving the mystery of the failed tests displayed in red text. While I understood why RSpec is utilized to help us pass our labs, learning code along the way, I didn’t understand why one would write up tests for one’s own code and I was also curious as to how RSpec came to be, as it is one of the more widely used testing libraries.
Learn.co uses RSpec, which is a testing library that is based upon behaviors. RSpec was initially created in 2005 in response to the birth of languages such as Ruby. The first version was released in 2007, with different versions being released throughout the subsequent years. Prior to RSpec, most developers were using TDD (Test-Driven Development), but it seems that developers were having a hard time fully making use of the test. Testing with TDD tested the object, instead of behaviours, thus if you changed your code from an Array to a Hash, but still got the correct result, your test would fail and would have to be updated. Constantly updating your TDD tests when you refactor your code can be costly, both in resources and time. Thus, TDD testing was sometimes shied away from. BDD (Behavior Driven Development), like RSpec, was much easier to work with as the specific code syntax mattered less, as long as it produced the desired results. Another advantage of BDD is how it written essentially in plain and simple language – you don’t have to be a programmer to understand what the test is checking for.
How does testing help us if we’re the ones writing both the tests and the code? One of the best ways to code is to state your end-goal(s), in simple language, without using code. If you write your tests first, you can figure out what results you are looking for and then move forward to obtaining them. When writing the code to pass tests, you write as little code as possible just to first get the tests to pass, which in turn may mean that you also write more concise code.
Prior to writing the tests, you need to ensure that you have the rspec gem installed. Then you have to run rspec –init in your terminal within the root folder for your coding project. This will automatically generate the .rspec file and spec folder. The spec_helper.rb file within the spec folder will also be automatically generated. You will need to point the spec_helper file to the file(s) in which you will have your code that you want to test.
When you create your tests, you will create them in a new file within the spec folder using a “_spec.rb” notation. Below is from one of the spec files for one of the first labs from Learn.co. Here, we can see that we first start with the describe block to introduce which object (in this case a file that we wrote our code in) we will be testing the behavior of. Then the context block, which is optional, shows in what context are we testing this object. This block makes it clearer to the reader the circumstances for this test. This block is followed by the it block which describes one of the behaviors of the object in question. Then, we put in the method whereby we can test these expectations. In the case below, this test is checking to see if our coding file has a variable called greeting and has it equal to “Hello World”.
describe “./variable.rb” do it “defined a local variable called greeting and set it equal to ‘Hello World’” do greeting = get_variable_from_file(’./variable.rb’, “greeting”) expect(greeting).to eq(“Hello World”) end end
The test is run by entering the below code into the terminal when you are withing your code root directory:
There’s also a wrong and a right way to write your specs. Some of the basics of writing good tests are:
- When you call your describe block on an object, make sure that you use your specific object’s name, using “.” for a class and “#” for a method in front of the name.
- Your descriptions should also be as concise as possible.
- Even though the context block is optional, it’s best to include it to make the test as clear as possible to the tester
- Make sure that each of your tests are testing a single expectation. Do not try to group multiple results within a single testing block.
- Try to think of all of the possible points the code could miss and try to account for them in your code.
- You can find more pointers at betterspecs.org.
- callahan – Getting Started with RSpec
- TeamTreehouse – An Introduction to RSpec
- RSpec Site
- The RSpec Book
- IBM RSpec