Feeds:
Posts
Comments

Archive for April, 2010

Overview

Every now and again I think I should maybe be integrating Javascript tests into my test suite. Then I take a look at the setup (Celerity, running in Java, plus Culerity, on top of my existing setup of RSpec + Cucumber + ROTS), and I think, “ick”.

Culerity & Co. probably makes sense for applications that are heavy on front-end modification using Javascript. But for my purposes, insofar as it is possible, I build my applications to work without Javascript, and then Ajaxify forms using jQuery. The JSON response includes the output of a rendered partial that replaces existing content already on the screen. Those partials are thoroughly tested via the standard, non-Ajaxian pathways.

The only part that has bitten me (and that not in a full-fledged production app) is when the underlying partial changes in some way that makes it incompatible with the way the partial is called when responding to JSON (for example, by making the partial require a new local variable).

Details

To ensure that all rendering pathways are tested, I added an RSpec example for every Ajax call. All it needs to test is whether the call is successful because all other aspects of the call are tested via the non-Ajaxian pathway. That gives the following:

  describe 'POST create via AJAX' do
    integrate_views
    it 'should be successful' do
      activate_authlogic
      UserSession.create(@contributor)
      post(:create,
           :node_id => @node.id,
           :score => 15,
           :format => 'json')
      response.should be_success
    end
  end

The “integrate_views” line is important. Usually, controller specs don’t render views, but in this case, the ability to render the view is the main thing we’re testing. It’s great that RSpec makes this option local to a describe block.

Advertisements

Read Full Post »