RSpec with Resque

resque rspec ruby on rails software development

So one of the gems we use a lot in our Ruby on Rails applications is Resque. For those who don't know, it's a library that allows you to run background tasks that are separate from the main web thread.

This gets especially useful when your web applications get big enough that they are doing long, complex tasks. There are alternatives like Sidekiq and Delayed Job, but Resque was the first one we came across and it's been serving us well for years.

However, one thing that became really annoying to deal with was automated tests (or specs). We use rspec, and when we would run our tests, a lot of the times our tests would fail because it would run into some code similar to Resque.enqueue which requires that your Redis server be running.

One way to deal with this was to simply start up your Redis server and then run your specs. However, this didn't feel right. With stubs, and mocks, and whatever else you use to fake logic, it seems that it should be easy to stub out any call that Resque makes.

Luckily, there is an easy solution.

It's called resque_spec and its repo can be found here.

It can actually do a bunch of stuff, but the key thing for us, is that it basically stubs out the real Resque calls so it doesn't actually queue up jobs, and doesn't require Redis to be running. What's more, the setup is as simple as including it in your Gemfile. Warning: As they mention, only include this in your test group, as it does override the default Resque functionality

# Gemfile

group :test do
  gem 'resque_spec'

What's more, if you're using Resque Scheduler, it works with that as well (with a little extra configuration).

With resque_spec in place, running specs became a lot simpler. Hope this helps some peeps out!

Casey Li
CEO & Founder, BiteSite

How to automatically execute your RSpec test suite before pushing code

Git Git Hooks TDD FactoryBot Faker Testing Capybara rspec ruby on rails

As you probably know from our previous blog posts, at BiteSite we recently started writing tests for our Rails apps using a combination of RSpec, factory_bot, and faker. We currently only write tests for our controllers and models. However, we are hoping to start writing some unit tests, and UI tests using Capybara.

Even though we love writing tests, we find that we can sometimes forget to run our test suite before merging code into our main branch. This can sometimes lead to failing specs making their way into our develop branch. To try and prevent this from happening, we decided to experiment with a continuous integration service, called Codeship. At first glance, Codeship seem to accomplish exactly what we wanted. However, we quickly reached and surpassed the free tier limit. Thus it was no longer running our test suite on new commits. We would eventually like to host our own CI server; however, we currently work at a shared office where we don't have control over the network setup.

This led me to come up with the idea of using Git hooks. Git hooks are scripts that are executed during a specific Git command. You can find the different types of hooks here I decided that I was going to use the pre-push hook that was introduced in Git version 1.8.2. Using the pre-push hook, I was able to write a script that ran our RSpec test suite before pushing code to our remote repositories. The Git pre-push hook will push your code if it exits with a zero status a cancel the push if it exits with a non-zero status.

At this point I wasn't sure how I was going to determine whether our test suite passed or not. So I decided to look into whether or not bundle exec rspec returned anything. Fortunately, if all the tests pass, bundle exec rspec returns a 0 if not, it returns a non-zero value. There we go! At this point I had everything that I need to create my pre-push script. Alright enough jibber jabber, let's get to the nitty gritty.

echo "Starting test suite..."

bundle exec rspec

if [ $? == 0 ]; then
  echo ""
  echo "================================================================================"
  echo ""
  echo "Congratulations 🎉 all specs passed!"
  echo ""
  echo "================================================================================"
  echo ""
  echo ""
  echo "================================================================================"
  echo ""
  echo "😡 the tests did not pass. No push for you!"
  echo ""
  echo "================================================================================"
  echo ""
  exit 1

exit 0

The script was actually a lot simpler than I thought. We simply run the bundle exec rspec command and check its output status and from that we can allow or prevent the code from being pushed.

If you wanted to try this out for yourself, navigate to your project’s root folder, then into .git/hooks/. Create a file called pre-push with no extension and copy the above script into it. Now we need to make the file executable, to do so, execute the following command from your terminal: chmod +x pre-push.

Now all you need to do is push code to your remote repository and it will run the script. Unfortunately, with the current implementation, you need to wait until the test suite is complete before you can do anything else. Next time we will continue with what we started and turn the script into a background job and use mac notifications to notify us of completion status.

Ryan O'Connor
Software Developer, BiteSite

Failing RSpec Tests when using RABL for JSON Responses

rabl coding software rspec ruby on rails

After about 5 years of doing Ruby on Rails development, there is one aspect that for the longest time never seemed to sit well with me: TDD. It wasn't that I didn't understand the benefits, and it wasn't that I didn't believe in it, but unlike many things Rails, there wasn't enough concrete motivation to do it. Over the past few months I finally started to get into it and I'll write all about my experiences in another post, but for now, I wanted to let you guys know about a specific problem I was having with TDD'ing an API I built.

I was building an API for a app using Ruby on Rails and following the

To render my JSON responses, I almost always use RABL now. I tried activemodelserializers when I was experimenting with Ember, but I quickly switched back to RABL.

Anyway, I was writing my tests I was having issues testing my JSON response. My typically test would look something like this:

it "renders a response" do
  get :index, format: :json
  response_object = JSON.parse(response.body)
  expect(response_object.size).to eq(1)

The issue is that no matter what I did, it seemed that my tests would fail. Upon further inspection, it looked like the response.body was empty. I was getting really frustrated so what I did was I abandoned my TDD and just tried it in the browser (well, more accurately in Postman). To my surprise, it was working.

So why were my tests failing and why was the response.body empty?

It all has to do with the fact that I was using RABL for the JSON responses. Because RABL uses Rails view rendering and by default Controller specs don't render views - the response.body was empty.

So the solution was as simple as adding


to the top of my specs so I had the followiing:

require 'spec_helper'
describe Api::V1::MyController, type: :controller do

Alright, that's it for now. Hopefully this helps some peeps.

Casey Li
CEO & Founder, BiteSite

Rails 4, Rspec not letting go of Gemfile.lock, can't Git Pull, can't checkout

coding software rspec

Alright, this is going to be a super quick post but thought I'd let people know as this has come up a couple of times.

The environment is

  • Rails 4 or above
  • Git
  • Rspec for testing

So here's the issue. Every now and then, I try to do a Git Pull (say after a pull request has been merged) and Git won't let me because it seems my Gemfile.lock has some local changes that would be overwritten.

Easy enough, right? Just stash, or discard the changes. So I tried running 'git stash', or 'git checkout Gemfile.lock'. But then right after, I do a 'git status', and low and behold, the Gemfile.lock still has local changes. What the hell? Why isn't Git letting me stash the changes.

Well, it turns out, Git is letting me stash the changes, but very shortly after, something is changing the Gemfile.lock file right away. So right after I stash my changes, or discard, something comes right back and makes the changes again.

The culprit? Rpsec- well more specifically spring. So after running rspec, spring continues to run. As far as I understand, spring keeps your Rails environment running so you don't have to reload it on every rspec run (as far as I know, I could be way off). But the short of it is, the first time your run rspec, it fires up spring, and spring holds onto your Gemfile.lock.

So after you discard your changes, spring will apply the changes right again on Gemfile.lock (and perhaps other files).

How to solve it?

Simply stop spring by running "spring stop". At that point, you should have no issue discarding your changes using Git.

Worried about spring being stopped? Don't worry, it starts up again the next time you run rspec.

Alright, that's it for now. Hope that helps some peeps!

Casey Li
CEO & Founder, BiteSite