For the past few weeks, I have been dreading the moment when I would have to utilize RSpec on a regular basis. Because RSpec is the testing framework for the Ruby language, I viewed it as an obstacle to my learning development. After studying more about RSpec in the past few days, I’m starting to realize that I have been viewing its fundamental purpose incorrectly. RSpec is a complement to the Ruby developer’s toolkit — it prevents unneccesary work by testing the behaviors of a framework. In short, it is the blueprint of any application, and represents a guided set of directions that leads you to a finished product.
In this blog post, I’ll discuss the basic premise of RSpec and also discuss a few ways to refactor RSpec code.
Here’s a simple example.
This example is to just show what RSpec was intended for in regards to test-driven development. See how RSpec determines how the calculator should behave when the multiply method is called? When given the parameters 4 and 5, the multiply method should return an integer value of 20.
“Subject” always refers to an instance of a class. In this case, James is an instance of the Person class, and the step of initializing a Person instance with the name James has been refactored by using “subject.”
This is a big change that I’ve started to implement in my RSpec tests, largely because of issues that have to do with delegation. There was a blog post (http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax) that discussed the differences between ‘expect’ and ‘should.’ My understanding of the Kernel library and the rspec-expectations are not very concrete yet, but it is partly a result of a library load. If one library is loaded before the other, it can sometimes override syntax delegations for the same word.
Another reason is that it seems a little more clear to me in terms of understanding what’s going on with the syntax, particularly when I am starting a new test from scratch. Should semantically makes sense if you’re writing tests for existing code, but not necessarily if you haven’t written a line of code yet.
Make yourself useful.