Building the stuff was actually very easy. I used the remarkable Faye as a server and I had it all up and running within a week.

I decided on an architecture that would allow the real-time tech we used to be as unubstrusive as possible. Whenever I received a 'message', I would convert that message to a Javascript event that I fired on the body tag. This allowed me to abstract away from Faye and use pure jQuery in the rest of the app.

Whenever we wanted behaviour based on a message I could just bind a specific callback to that event from anywhere.

Using this architecture I started converting Caren (our app) to use as much real-time stuff as we could. It was awesome. Life was great.

But then I hit a wall. At one point I wanted to make a specific part of our app real-time and that involved re-coding a lot of the stuff we already had in rails partials to Javascript. Damn, duplication.

We couldn't remove the rails stuff because you still needed that for the old stuff that was already in the database. This was the first real obstacle we hit. Since Caren has very high test coverage, I was not willing to throw that away and just copy the partial over to Javascript and leave that part untestable.

I needed to solve two issues: First, I didn't want to code the stuff again. Second, I wanted it to be testable.

The first solution was relatively easy, although I am still contemplating if the nastyness is worth the lack of duplication. Time (or the comments) will tell.

I decided to create jQuery templates from my Rails partials. Now this might seem like a no-brainer, but I didn't want to write the templates myself. I wanted rails to generate them from my original partial. Enter the nastyness.

  jquery_template "personal_message_by_other", "/messages/message", locals

Now you might be thinking: this doesn't look so bad. Wait for it.

  def jquery_template id, template, locals={}
    tmpl = capture{ render(:partial => template, :locals => locals) }.gsub(/\n/,'')
    tmpl = ""
    tmpl = tmpl.gsub('http://$','$')
    tmpl = tmpl.gsub('%7B','{').gsub('%7D','}')    
    return tmpl.html_safe
  end

Again, not that bad. But getting there. Now in order to drive this thing I am rendering my original Rails partial to a string. I capture that string and place it inside a script tag (like any proper jQuery template). The magic happens in the locals.

The locals I pass normally are the ActiveRecord objects of my rails app. But for the jQuery template I use fake objects. That look like this:

  class Templates::Base

    attr_accessor :acts_as_new_record

    def initialize options={}
      if options[:acts_as_new_record].nil?
        self.acts_as_new_record = true
      else
        self.acts_as_new_record = options[:acts_as_new_record]
      end
    end

    def to_key
      ["${id}"]
    end

    def id
      "${id}"
    end

    def to_s
      self.id
    end

    def new_record?
      self.acts_as_new_record
    end  

    def persisted?
      !self.acts_as_new_record
    end

  end

They mimic an ActiveRecord object but instead of the database values, they return stuff like "${id}". This is what jQuery uses to replace values. This works like a charm. There are some snags: everything the rails partial echo's into the html must be a method on both the real and fake ActiveRecord model. This is especially interesting if you are using localization.

I use these templates together with the content of the message I get from faye. Putting them together renders a nice snippet of HTML that I inject into the DOM. Life is good again.

Now off to the second part. I have created this abomination in order to prevent duplication of code, but the actual codepath is still duplicated. Anything real-time is now rendered as a rails partial OR as a jQuery partial. And I am only testing the rails partials, since... well Javascript integration testing sucks.

But I wanted it tested. So I decided to bite the bullet. Caren uses Cucumber with Akephalos for integration testing. My first test was a horrible failure. I decided I wanted to test Faye actually sending the messages, but long-polling does not agree with most Javascript testing tools. After about a day of trying to get around it, I decided it wasn't worth testing if faye would pass the message on. I was more interested in the reaction to that message.

At the end, my stories looked like this:

  Scenario: Changing notes in real-time
    Given I am on Andre's page
    When Andre's "note" is updated to "Test notitie!" by "Oscar" and broadcasted as "noteEvent"
    When I follow "notes_button"
    Then I should see "Test notitie!"

And the core step in this story is implemented like this:

  When /^([^"]+)'s "([^"]+)" is updated to "([^"]*)" by "([^"]*)" and broadcasted as "([^"]*)"$/ do |person, field, value, updater, event_name|
    prev = Person.current 
    Person.current = Person.where( :first_name => updater ).first
    Person.where( :first_name => person ).first.update_attribute(field.to_sym, value)
    message = Activities::Activity.last.push[:data]
    page.driver.execute_script("page.pushClient.triggerEvent('#{event_name}',#{message.to_json})")
    Person.current = prev
  end

As you can see I manually trigger the event with the content (json) that my Rails app generated for me. This is as close to a real situation I could get. And this worked! Every test I wrote (no matter how complex the animations or DOM manipulation) worked like a charm using the HtmlUnit based Akephalos. Unfortunately when running the stories in a row, it all went to hell.

Meet the bane of my existence:

  Mysql2::Error: This connection is still waiting for a result, try again once you have the result

Huh? What? What does that even mean? People here agree: https://github.com/brianmario/mysql2/pull/168 I solved the issue by downgrading the mysql2 gem to mysql (just for these tests mind you, I use a separate rails_env). But that's not all. Since Akephalos uses a remote server to run the tests that need to share the same Mysql connection pool, more freakyness occurs. How about this one:

  Undefined method collect on NilClass

This one kept coming back, at random intervals. Sometimes it did, sometimes it didn't. This exception was raised on the following code:

  CareProvider.first

Yeah, that's freaky right? This was pure ActiveRecord code. After some investigation I found the culprit: ActiveRecord QueryCache. Apparently it did not play well with the tests. After I disabled that, it was smooth sailing.

  if Rails.env.javascript_test?  
    module ActiveRecord
      module ConnectionAdapters
        module QueryCache
          private
            def cache_sql(sql,binds)
              yield
            end
        end
      end
    end
  end

So now I have a fully tested RealTime web app. What do you think, worth it?