[rspec-users] Controller actions do a bunch of javascript stuff...can I use spec that?

David Chelimsky dchelimsky at gmail.com
Mon Jan 8 08:40:23 EST 2007

On 1/8/07, Pat Maddox <pergesu at gmail.com> wrote:
> I've got a form that isn't doing a regular POST...what actually
> happens is that when onClick gets called, a bunch of javascript stuff
> happens.  It changes the form's action to be a different URL.  Then it
> polls for progress on another server, and when it's 100% reverts back
> to the initial URL.
> I know that sounds really ugly (and I agree it is), but that's the way
> it has to be at this point.  Working with a "legacy" system.  Is there
> any way I can spec that behavior with rspec?  I sort of assume not,
> since it's highly dependent on JS...probably need to use jsunit for
> that instead.  Still I've love to hear any ideas, as well as how I
> could move more of the behavior into Ruby instead of JS.

I would test stuff like that in the browser using selenium or watir.
There are existing hooks, like Selenium Remote Control, that allow you
to drive these browser-based testing frameworks from ruby files. We're
adding more integrated hooks into rspec for the next release as well.

As for pushing the behaviour down to ruby, I can imagine a couple of
options. One would be to have the onClick remote-link to an action
that replaces the form tag and introduces a new javascript block that
remote-links back to another action. The second action responds by
polling for progress on the new server and updating the page w/ the
same remote link (calling itself again) until the server responds
100%, at which point the second action restores the form tag.

Another approach might be to have the onClick remote-link to an action
that sets a variable in the session like
session[:server_update_complete] = false, invokes the server update,
starts polling for completion, and then sets
session[:server_update_complete] = true when it gets back 100%. The
form action would never change on the page, but the action would be
written to check for that session variable and redirect to the
appropriate action.

I'm sure both of these have pitfalls that I'm not thinking of. Just a
couple of ideas to bat around.


> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list