10 Things I wish I knew before testing my Rails Application with rspec for the first time [Part 2]

This article is the second part of my “10 Things I wish I knew before testing my Rails Application with rspec for the first time” series. In case you haven’t read part 1, here is the link.

Photo by Kevin Ku on Unsplash

It has been some time since my Part 1 article, we are living crazy days, but better late than never… Here we go!

1. Webmock
   You’ll eventually reach the point where your application has to perform HTTP requests to external services. You can mock that service creating a “fake” web application using Sinatra for example, but that can be hard to maintain. Instead I prefer to use webmock, a library which will allow you to both stub and set expectations on any HTTP request your application does. It also has a very cool feature to disable all real network requests so you don’t end up doing any real request that will affect any production system by mistake. It works really good with rspec (and other frameworks too).
2. Omniauth test mode
   In case you are using Omniauth, I found using test mode to be really useful. This mode makes Omniauth “short circuit” all request made to “/auth/<your_configured_provider>” to “/auth/<your_configured_provider>/callback”. You can configure as many providers and responses as you like.
3. Test Controllers and Routes using Requests Tests
   This point is really opinionable, and it’s fine if you don’t agree with it. That being said, the more tests you create, the most tests you will have to maintain. Maintaining a robust tests suite takes time and effort, so you will really want to put that limited time and effort focused in what really matters. That’s the main reason why in my team, we decided to use request tests to test both our routes and controllers, instead of having each one tested separately using its own kind of request.
4. Mocking & Stubbing
   I highly recommend reading “Mocks Aren’t Stubs” lecture from Martin Fowler to better understand the difference between them. I use RSpec for mocking, mostly for classes that interact with external services or to force some kind of error situation.
   TIP: Don’t forget to check the “Verifying Doubles” documentation, so you don’t end up having mocks that can do things that your real object can’t.
5. Shared Contexts and Examples
   It comes a time when you find yourself writing over and over the same context and examples…. that’s when Shared Contexts and Examples come in very handy to apply some DRY principles to your test suite.
   I have a hard time writing them from scratch, so I normally create them once I find that I’m repeating the same thing for the first time, that should be your queue to stop writing, and move the duplicated stuff into it’s shared form. Take my advice, do this before it’s too late or you’ll end up with very long test which are mainly composed by duplicated code, which kinda converts into a refactor hell when you have to change something.

I hope you enjoyed the reading, and please comment if you would like to see some of these topics covered in more detail or if I missed something that you consider to be important.

Happy Testing!