Using Jasmine to test CoffeeScript in a Rails 3.1 App

Wednesday, May 11, 2011

Lately I’ve had the opportunity to use Jasmine to test drive a whole bunch of Javascript and am loving it. If you haven’t had a chance to take Jasmine for a spin, I recommend you take some time to do so.

When I heard that Rails 3.1 was going to include CoffeeScript I decided to work to figure out how I could write both my production code as well as my specs in Coffeescript.

Using this gist as a guide, I came up with these detailed instructions:

Add Guard and Guard-Coffeescript to your Gemfile and run bundle.

Run guard init to create a Guardfile and edit it to contain the following:

guard 'coffeescript', :output => 'public/javascripts/compiled' do
  watch(/^app/assets/javascripts/(.*).coffee/)
end

guard 'coffeescript', :output => 'spec/javascripts/compiled' do
  watch(/^spec/javascripts/(.*).coffee/)
end

Edit your spec/javascripts/support/jasmine.yml to have at least the following entries:

src_dir: public/javascripts/compiled
src_files:
  - **/*.js

spec_dir: spec/javascripts/compiled
spec_files:
  - **/*_spec.js

Start up the Jasmine server using rake jasmine and point your browser to http://localhost:8888. You should see 0 specs, 0 failures. Since you have changed the location that Jasmine looks for spec files, you aren’t picking up the example Jasmine specs any longer.

Create a new spec file in spec/javascripts/math_spec.coffee with the following contents:

describe 'Math:', ->
  describe 'fib()', ->
    it 'should calculate the numbers correctly up to fib(16)', ->
      fib = [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987]
      expect(Math.fib(i)).toEqual fib[i] for i in [0..16]

Refresh your browser, you should see one failing spec. Guard has compiled your .coffee file into a .js file that Jasmine will use.

Create a new implementation file in app/assets/javascripts/math.coffee with the following contents:

Math.fib = (n) ->
    s = 0
    return s if n == 0
    if n == 1
      s += 1
    else
      Math.fib(n - 1) + Math.fib(n - 2)

Refresh your Jasmine browser window and you should see 1 passing spec. Again, Guard has compiled your implementation file and Jasmine uses it to satisfy the spec.

At some point, it would be nice to figure out a way to run Jasmine specs directly from the .coffee files and against the implementation .coffee files without having to use Guard to compile them. With the above steps, you still have to check in the compiled files into source control so your tests can be run in the CI environment. If you miss one of the compiled specs or one of the compiled implementation files, your CI environment may report improper results.

If anyone has any ideas, I’d love to hear them.

NYC Standup: 2011-04-18

Pivotal Labs

Monday, April 18, 2011

Interestings

“respond_to :not_fun”

When using
respond_to
in a controller in Rails 3, keep in mind that the body of the action will still happen before it doesn’t find a
format
it is interested in and bails, possibly causing side effects of the action to still happen (like creating a record) but returning a 406 or other error to the client.

“Time.stub(:now) combined with waits”

Careful when stubbing
Time.now
when using, for example, steps in Cucumber that are “waiting” for things, as the clock will not move, and your tests will run until the end of time…

Making sure you implement the ActiveModel interface fully

Mike Gehard

Friday, April 8, 2011

Rails 3 brings with it ActiveModel.

ActiveModel give you a way to make non-db backed models look like db backed models to your views and controllers. See this post for a good explanation of what using ActiveModel buys you.

ActiveModel gives you a great way to test that your class implements the minimum ActiveModel interface: ActiveModel::Lint::Tests

Check out this gist for the details for using these tests in RSpec:

Testing OmniAuth based login via Cucumber

Mike Gehard

Thursday, March 3, 2011

If you haven’t looked at OmniAuth for authentication with sites like Google, Github and Facebook, then you should take a look. It is pretty killer.

This morning we needed to write a Cucumber scenario to test that a user could log into the system using Google Apps.

We did a quick spike on getting OminAuth integrated, which was a super simple process, and poked around in the browser to make sure it was working OK.

Thanks to Jose Valim for providing some guidance, via the Devise test suite, on how to get this all up and running.

The basics can be found in this Gist:

I put that code in /features/support/omniauth.rb and then all I need to do is label any scenarios that need to deal with login with an @omniauth_test tag and we are all set.

As our features count grows, I could see us doing this before/after all Cucumber scenarios.

Note: You need to be using 0.2.0.beta5 of OmniAuth to get this to work. Earlier versions don’t have the testing functionality built in.

Also Note: This same functionality can be used in good, old RSpec integration tests or Steak tests as well.

revealing the ActionController callback filter chain

Nate Clark

Tuesday, February 1, 2011

Sometimes your controllers get so full of before_filters, after_filters, and around_filters that it’s hard to figure out what order these callbacks are actually executing in. A couple of times recently, I’ve run into some tricky bugs that ended up being related to callbacks running too soon or too late.

Due to some fancy-pants metaprogramming in AbstractController::Callbacks, it’s hard to see what’s going on.

In Rails 3, send this to Rails.logger.debug or puts from inside your controller to see the ordered filter callback chain:

_process_action_callbacks.map(&:filter)

RSpec 2 Gotcha with polymorphic_path

Pivotal Labs

Wednesday, December 8, 2010

A quick gotcha we ran into when using polymorphic path and rspec2 today.

In a controller test we had an assertion:

response.should redirect_to(polymorphic_path(@some_object))

Which resulted in the following error

Failure/Error: Unable to find matching line from backtrace stack level too deep
# ~/.rvm/gems/ruby-1.9.2-p0@gemset/gems/rspec-expectations-2.1.0/lib/rspec/matchers/method_missing.rb:4

It turns out polymorphic path is not available in the controller test (but the usual object_path method is). As to why this throws a stack level too deep and not a method undefined looks like potentially another bug in rspec but the solution seemed to be to do the following in our spec_helper.b for Rails 3:

include Rails.application.routes.url_helpers

For Rails 2.x you’ll want to use:

include ActionController::UrlWriter

I’ve opened an issue for this on github as well https://github.com/rspec/rspec-expectations/issues/issue/46

Are Rails plugins still necessary?

Mike Gehard

Monday, December 6, 2010

Back in the day, plugins were an acceptable way to extend Rails because gems were hard to create and publish. It was easier to just put up a public repo and have people pull a plugin from there.

In Rails 3, I think that we’ve got a good solution to these problems. Bundler allows us to type bundle gem and quickly get the skeleton of a gem. Bundler also also allows us to easily pull in unpublished gems via the :git option from any public git repo. The new rubygems.org allows us to easily publish gems that are ready for prime time.

Yes plugin maintainers will need to take a little time to update their plugins to be gems but I think that time is outweighed by the benefits of less code in Rails (because the plugin architecture code will be removed), possibly increased startup time because less code is running and adhernace to a standard way of loading Ruby extensions via the gem mechanism.

What do people think?

A lot of hard work has gone into modularizing the Rails3 codebase to make it easier to work with and faster.

Do we continue the spring cleaning and get rid of other remnants from the past?

Devise 1.1.3 gotcha…

Mike Gehard

Friday, November 5, 2010

In the continued saga that is the Rails 2.3.10 to Rails 3.0.1 upgrade, I found this little nugget today…you want to add a custom action to a controller that inherits from a Devise controller. Here are the steps that you need to follow:

1) Create a custom controller that overrides some out of the box Devise actions as well as adds a new method.

class RegistrationsController < Devise::RegistrationsController
  def update
     # do something different here
  end

  def deactivate_owner
    # deactivate code here
  end
end

2) You have to tell Devise to use the new controller in routes.rb as well as add the new route to the new action.

devise_for :owners, :controllers => { :registrations => "registrations" } do
  post "deactivate_owner", :to => "registrations#deactivate_owner", :as => "deactivate_owner_registration"
end

When we initially implemented this, our route definition looked like this:

post "deactivate_owner", :to => "registrations#deactivate_owner", :as => "deactivate_owner_registration"
devise_for :owners, :controllers => { :registrations => "registrations" }

When it was implemented this way, we kept getting a AbstractController::ActionNotFound exception. Once we passed the block to devise_for seen in #2, everything worked fine.

Rails3, Caypbara, Cucumber, FakeWeb…oh my….

Mike Gehard

Thursday, November 4, 2010

While helping client upgrade a Rails 2.3.10 site to Rails 3.0.1, I came across a very perplexing problem with our WebDriver based Cucumber tests that all worked fine under 2.3.10.

We were “randomly” getting some very strange errors from Cucumber having to do with timeout problems and other strangeness like Cucumber not being able to find form fields to fill in.

The solution:
1) require => false for the FakeWeb line in the Gemfile
2) add require ‘fakeweb’ to the top of the test_helper.rb file

or optionally scrap FakeWeb for either Artifice or WebMock

It has something to do with FakeWeb inserting it into the HTTP stack strangely even if you tell it to allow non-local HTTP requests. We weren’t seeing it in 2.3.10 because we were using a cucumber environment to run the cucumber tests. Now under 3.0.1 we run the cucumber tests in the test environment.

I wish I had some more details but I was just happy to move past this strangeness so I didn’t really look back.

Testing Rails3 Generators using Cucumber and Aruba

Mike Gehard

Wednesday, September 15, 2010

In an effort to continue my contributions to the open source Ruby/Rails ecosystem, I decided to help the factory_girl_rails team move the Rails3 generators from the rails3-generators project into the factory_girl_rails project.

Like all good Ruby/Rails developers, they asked to make sure that I had tests written around the generators. I thought for a bit on how I was going to do this and then I wandered across the Cucumber feature files in the rspec-rails repo and found my answer.

Rspec-rails (and RSpec2 as well) uses a gem called Aruba to easily write Cucumber features around things that happen from the command line.

If you’d like to check out the result of using Cucumber and Aruba to test Rails3 generators, head over to my fork of the factory_girl_rails gem and check out the features/generators.feature file.

Hopefully the changes will be merged into the official factory_girl_rails repo soon and the generators will live closer to home.