[rspec-users] Is it still possible to use should_have_rjs

Ashley Moran work at ashleymoran.me.uk
Fri Jun 15 11:55:25 EDT 2007

On 15 Jun 2007, at 12:42, David Chelimsky wrote:

> You're not missing anything. I switched from a direct port of ARTS to
> wrapping assert_select_rjs in 0.9. Neither library covers the full
> breadth of rjs statements and I went w/ the wrapper because it meant
> that rspec would reap the benefits of improvements to
> assert_select_rjs. Sadly, it seems as though the only improvements to
> assert_select_rjs have been those that I've personally contributed to
> Rails, and they haven't covered every situation.

Hmm, surely RJS testing is a pretty essential part of Rails, seeing  
how everyone's going Web2.0-crazy?  I'm surprised assert_select_rjs  
doesn't cover everything.

> As for your immediate problem, Spec::Rails provides access to
> Test::Unit assertions for free. I'd recommend that you install the
> ARTS plugin (from which should_have_rjs was ported) and use it
> directly as/is (assert_rjs) right in your examples. It won't be as
> pleasing syntactically, but at least it should work for you.
> http://glu.ttono.us/articles/2006/05/29/guide-test-driven-rjs-with- 
> arts

Thanks for the link.  I tried this:

describe "A rendered add_dealer view" do
   before(:each) do
     render 'admin/add_dealer'

   it "should have visual effect" do
     assert_rjs(:effect, :blind_down, "add_dealer")

But it doesn't work:

should have visual effect
ActionView::Helpers::JavaScriptProxy#to_str should return String
config/../vendor/plugins/arts/lib/arts.rb:98 :in `index'
config/../vendor/plugins/arts/lib/arts.rb:98 :in  
config/../vendor/plugins/arts/lib/arts.rb:12 :in `assert_rjs'
97  def assert_response_contains(str, message)
98     assert @response.body.to_s.index(str), message
99  end

My naive attempt to fix it...

module ActionView
   module Helpers
     class JavaScriptProxy
       def to_str

achieves nothing.  (Probably because it's completely wrong.)  Any  
ideas on this one?

> There are a couple of things that ARTS didn't cover that we had added
> to RSpec. Those you'll have to do manually with any of these:
> response.should have_text("full text of the response")
> response.should have_text(/regexp representing a substring of the  
> response/)
> response.body.should == "full text of the response"
> response.body.should =~ /regexp representing a substring of the  
> response/
> In terms of a longer term solution for rspec, I'm open to suggestions.
> ARTS and assert_select_rjs both make assumptions about what options
> are available, which means they both need to be updated as new options
> appear. I had hoped that this would be maintained in rails, but it
> doesn't appear to be happening.

Hmm, surely a framework feature without a means to test it is next to  
useless?  Or maybe I am being a too demanding (I'm known for it).

> We could resurrect ARTS in RSpec, but that would mean either coming up
> with a new matcher (include_rjs?) as not to break existing specs that
> use "should have_rjs.", and it would put more of a burden on
> Spec::Rails to keep up with additions to rjs.

Is there any way to be clever with have_rjs and decide where to pass  
the request based on the type of match?  That way you could use ARTS  
as a prop and migrate test support to assert_select_rjs as and when  
things as included?  I haven't written any custom matchers yet -  
don't know much about the new style specs thanks to lack of time  
spent coding - so again I'm probably being naive.


More information about the rspec-users mailing list