Spree meets Travis CI

At Made we love using Spree, it is the platform that powers all our recent eCommerce builds. Spree has a great community behind it who churn out some fantastic extensions that, when combined, can pull together a platform to fulfil almost any client requirement.

For me one thing that makes Spree stand out from its contemporaries is the quality and quantity of its test coverage, and the visibility of those tests.

If you are going to contribute back into the community with an extension you need to be ready to build something with an equally high level of code coverage. All the the tests within Spree use RSpec, and in my opinion any developer starting out writing an extension should follow this convention. I’m not saying you have to use the RSpec matchers, in fact many extensions use the shoulda matchers, but as the convention exists it should be adhered to.

Another convention that exists within the Spree community is using Travis CI to run tests. Travis CI is a continuous integration platform that integrates with any open source GitHub repository on the free pricing tier. The results of the tests can then be displayed on your extension’s README, and can be used to ensure any pull requests are good to merge and won’t break functionality.

**Getting Started with** **Travis** **CI**

Spree core has a generator included that will scaffold an extension for you, including a basic spec_helper ready to start your RSpec tests, so once you’ve populated your gemspec and committed into GitHub you are ready to use Travis CI.

Activating any open source repository is quite simple: all you need to do is sign in with GitHub and toggle a switch to add the Travis CI web hook to your repository. Then, once you have a valid .travis.yml in your repository, every time you commit a build will be scheduled.

The integration tests you’ll be running will require a headless browser. This will run out of the box over CLI, but within Travis you have to boot X Virtual Framebuffer (xvfb) before you can use Selenium/Poltergeist. To use xvfb you need to pass in some commands into the before_install commands.

before_install:  
  - "export DISPLAY=:99.0"  
  - "sh -e /etc/init.d/xvfb start"

Part of the beauty of Travis CI is the ability to test your code against multiple environment configurations. It’s as simple as listing the required ruby versions and different databases adapters within the config, and your test suite will be run against every permutation. While the convention for Spree is for each version to have its own branch (and therefore .travis.yml), this isn’t necessary; as Thoughtbot demonstrates with Paperclip you can also vary the gems within a single branch.

**Moar pill images!**

Whilst you have (of course) created a great extension, the inclusion of a Travis CI badge in your README will give your users confidence that your extension is a quality product and integrates well with Spree.

However there are plenty of other status “pill” images you can add to your repository to increase the visibility of your coding genius, many of which are listed in this gist and aren’t necessarily for RoR projects.

Out of those listed, I would recommend implementing Code Climate, Coveralls and Brakeman, which are all free to open source projects. These extra pill images will measure code quality, code coverage and test your extension for any security vulnerabilities.

**A basic .travis.yml**

The below YAML is taken from a recent extension I wrote, it’s quite basic compared to some but it is a nice starting point.

language: ruby
rvm:  
  - 1.9.3  
  - 2.0.0

before_install:
  - "export DISPLAY=:99.0"    
  - "sh -e /etc/init.d/xvfb start"

before_script:  
  - "bundle exec rake test_app"

script:  
  - "bundle exec rake spec"

notifications:  
  email:    
    - [seb@madebymade.co.uk](mailto:seb@madebymade.co.uk)

branches:    
  only:    
    - master

Useful Links

• Spree Extension Tutorial
• XVFB manual
• Environment Variables on Travis CI
• Building a Ruby Project on Travis CI
• Travis yml linter

About the Author