Baseline - an empty Rails 4 + Ember app

来源:互联网 时间:1970-01-01

Last night we were wondering how much work is involved in taking a stock Rails 4 application, removing turbolinks and turning it into something ready for doing BDD of an Ember.jsapplication. “Can’t take too long” we thought to ourselves. Famous last words.

Baselineis just this, an empty Rails 4 app, with the environment configured to allow you to immediately start adding your features with Ember on the front-end and a Rails API on the backend. We realise this is a pretty opinionated project, but we all love opinions, right? That’s why we use Rails and Ember in the first place. Let’s talk about some of the things that we’ve added:


In the Rails community, it’s kind of a standing gag that it’s the convention of the community to break with convention and remove the minitest test suite that Rails defaults to and add RSpec. We use RSpec for unit testing our code, and doing functional tests of controller actions. What we love about RSpec is the way that it allows us to build up execution contexts by nesting describeand contextblocks which are then lazily evaluated for each execution context, for example:

describe Api::RootController do describe '#index' do let(:query) { get :index, format: :json } subject { query; response } it { should be_success } describe 'JSON' do subject { query; JSON.parse(response.body) } it { should have_key('current_user_url') } end endend Cucumber

We use Cucumber as our acceptance testing system. It’s pre-configured with Poltergeistto drive the headless webkit brower PhantomJSto make sure that our front-end application behaves as expected. One of the nice things about Cucumber is that it uses a plain-english style syntax (called gherkin) to allow us to write our test scenarios in plain english, for example:

Feature: Contact page. Scenario: A user visits the contact page. When I visit '/' And I click the "Contact Us" link Then I should see 'Contact' And the "Contact Us" link should be active Jasmine

Jasmine is a test framework for JavaScript with a syntax that closely models RSpec’s “spec” style. It uses JavaScript functions in a similar way to the way that RSpec uses blocks to build up execution contexts. When you mix that with CoffeeScript you get a pretty reasonable spec syntax:

describe 'Ember.js', -> it 'is the expected version', -> expect(Ember.VERSION).toEqual('1.0.0-rc.6') Guard

Guard is a ruby-based file watcher. This doesn’t sound that amazing, but it has a great plugin architecture and great support from the Ruby community meaning that there are a whole lot of guard plugin gems available. we’ve wired up Guard with the various plugins to have it start a complete development environment, including Rails, Sidekiq, RSpec, Cucumber and Jasmine. Guard watches for file changes, and then uses the rules in it’s Guardfileto start, restart or run the various plugins. For example, when you modify any files in config/it restarts Rails & Sidekiq, when you modify something in app/models/it runs the corresponding unit tests in RSpec, and when you modify something in app/assets/javascripts/it runs the corresponding unit tests in Jasmine. This gives you the instant feedback needed to do effective BDD and TDD.

Continuous Flow

We’re strong proponents of the continuous flow style of Agile software development and along with that we feel that continuous integration (ie automatically running the full test suite every time you commit) and continuous deployment (automatically deploying your code to production whenever you merge to master and the tests pass), so we’ve made a point of setting up Baseline on Codeship(an excellent cloud-based service for CI and CD) to automatically test and deploy any changes as they happen to Heroku, so that you can see straight away any changes that you make. You can see the current build of Baseline running at

There’s much much more to talk about in Baseline, and we expect it to be the subject of a number of blog entries in the future. Watch this space.