The Wonderful(ly Frustrating) World Of RSpec.
My brain is a gosh darn prodigy when remembering stuff like:
Chewing gum jingles. Harry Potter spells. Pretty much any SpongeBob episode. Seriously, I can recite word for word (and what I think is pitch for pitch) the striped sweater song.
But test specs? Which are a critical part of my job? Forgetaboutit. That’s all mixed up in the lobe that forgot how to do algebra.
I wish I could say I know what I am doing, but instead I spent the better part of a week reading and studying up on RSpec basics. I mostly read from the GitHub RSpec readme as well as Jason Swett’s Beginner’s Guide to Rails Testing.
If you, like me, struggle with the vast world of testing (there’s no shame here!), join me in going back to the basics.
There are two different ways of testing a rails application: minitest and RSpec.
Though minitest is the default testing framework, RSpec is the most widely used. Think of RSpec as a detailed explanation of how the app is supposed to function - kind of like the Krabby Patty formula.
RSpec is made up of several different types of specs that provide different areas of coverage or explanations for how an app should work. Let’s go through the 8 types of RSpec specs according to Jason Swett’s guide to testing.
Model specs
- Spoiler alert: model specs test your models. Jason uses a larger number of these tests in comparison to system specs. Model specs are used to test methods and find validations. When testing model methods with your model specs, you should be writing the test first and letting it fail before adding a new line of code to ensure that the test fully encapsulates the method. This type of testing is also known as red/green/refactor testing.
System specs
- These are “high-level” specs that simulate a user’s keystrokes and mouse clicks. This is a very important test because it will emulate what a user does and makes sure the user is able to use the website as intended.
- This is used so often by Jason that he created a repeatable process for writing integration tests.
- Creating a record with valid inputs (this could be signing in a user)
- Trying to create a record with invalid inputs (i.e. leave the form blank)
- Updating a record (could be changing the name, or adding more information)
- The only downfall with system specs is that they are more work to write and more expensive to run than other tests. So they should be used thoughtfully.
In the guide, Jason mentions that the following specs are rarely used, as they are made redundant by system or model specs. But hey, learning is fun and mastering your craft means knowing about ALL your options.
Request specs
- These specs test controller actions in isolation. There are only a few instances in which you would use request specs instead of feature specs:
- If you are working on a legacy project with fat controllers. Sometimes these specs help refactor the controller code.
- When configuring an API-only rails app. System specs are impossible to use, so request specs are needed.
- If it’s too awkward or expensive to use a system spec.
Helper specs
- As the name suggests, helper specs test out helper methods.
View specs
- A view spec renders a view in isolation, with template variables provided by the test rather than by controllers.
Routing specs
- There isn’t much value from using these since routing is covered in system specs, but they can be helpful when an app has customized routes or uses slugs.
Mailer specs and job specs
- You guessed it! Mailer specs test your mailers and job specs test your background jobs.
- Jason’s recommendation: “To test my mailers and background jobs, I put their code into a PORO model and write tests for that PORO.” PORO stands for plain old ruby object.
IN SUMMARY:
8 different types of spec files.
95% test coverage achieved by using just model and system specs.
^^Start here when you begin coding, and you’ll feel way less overwhelmed.
If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.