THE BITESITE BLOG
Git icon 1788c

How to automatically execute your RSpec test suite before pushing code

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

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 https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks. 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.

#!/bin/sh
echo "Starting test suite..."

bundle exec rspec

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

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.

Ryanoconnor
Ryan O'Connor
Software Developer, BiteSite
Rspecrabljsonresponses

Failing RSpec Tests when using RABL for JSON Responses

coding software ruby on rails rspec rabl

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 http://apionrails.icalialabs.com/.

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 create(:route) get :index, format: :json response_object = JSON.parse(response.body) expect(response_object.size).to eq(1) end

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

render_views

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

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

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

Caseyli
Casey Li
CEO & Founder, BiteSite
Rspecgemfilelock

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!

Caseyli
Casey Li
CEO & Founder, BiteSite