An Introduction to RSpec
Learn how to setup RSpec and how to write the best tests.
RSpec is a testing framework used solely for Ruby and Ruby on Rails. The “R” stands for Ruby and the “Spec” stands for specifications, which basically means does this Ruby code exhibit the expected behavior in a controlled context. You can use RSpec testing on any script difficulty, from printing a string to the terminal to financial web applications. Generally, tests are used on more complex logic but let’s go over that later. First, what is a test?
Let’s say, you create a tic tac toe game and want to see how your position will change if you select a certain slot. This is testing. Testing is also when you submit a form on your web application using a hundred character email address knowing full well that you’ve set the email character limit to 25.
The difference between those tests and RSpec is that those tests are manual, RSpec is automatic. For simpler scripts you may be fine doing manual testing but for those complex web applications automatic testing is vital. Without testing you would need to go through each manual test every single time you make a small change anywhere to ensure your application didn’t fall apart. That’s a ton of wasted time right there.
Need to Knows
First thing to know about RSpec is that it tests in three steps: “given”, “when”, and “then”. Let’s say we’re testing the following print_string
method.
1 2 3 4 |
|
Given that the
print_string(arg)
method is run…
When arg is equal to “World”…
Then we should expect “Hello World” to be returned
1 2 3 4 5 |
|
The second fact to know about RSpec is that it is a Domain-Specific-Language. This means that although RSpec is Ruby it may not be exactly like the Ruby used in your Controllers or Models. Read more about DSL’s here!
Why Should You Test?
Before I tell you why testing is important I’ll disclose a reason not to test. Testing, if done extensively, can take up a lot of time and as the age old saying is “time is money”. So, if you need to desperately get that initial application out the door then you may choose to forego testing temporarily. But remember, do it soon or it will bite you in the ass!
Now, why you should actually test
○ Testing finds bugs
○ Makes you actually think about your code
○ Covers edge cases (like that hundred char email form submission)
○ Exposes crappy code
○ Makes refactoring and improving code loads easier
○ Saves development time (oh a bug? write a test for it! … Boom, time and money well saved!)
Not All Tests Are Created Equal
“If you don’t care about quality, you can meet any other requirement”
Yes, your whole code needs to work but some tests are more important than others.
○ Really complex logic is SUPER IMPORTANT! For instance, comparing the air-speed velocity of an unladen African swallow to that of a European swallow.
○ Priorities, test the code that is most important to your project succeeding. For example, keeping your user’s password private, a necessity for success.
○ The Happy Path, what should happen when your user succeeds in doing what they’re doing.
○ The Unhappy Path, what should happen when your user does not succeed.
○ Edge cases
○ Extraneous bugs
What you should not test is rather simple…
○ Don’t test basic code like “Hello World”.downcase(), Rails and it’s libraries and gems have their own built-in tests.
○ Third-party APIs, they also have their own tests
○ Already tested code
Words of Warning
○ Bad, partial, or broken tests are worse than no tests. If you know it won’t work don’t use it!
○ Keep test suites fast, you shouldn’t run tests and have it complete 24 hours later.
○ Run tests often, every time you make a change
○ Run test before pushing code
○ Brittle tests suck, make them hard as nails
Keep on being badass programmers!