DRYing up view tests...

OK, here is some rough code that implements a portion of the above:

  def assert_form(form_url, model_obj, opts={})
    assert_post_form form_url
    @form_url = form_url
    @model_obj = model_obj
    yield self
    assert_submit form_url, (opts.has_key?(:submit) ? opts[:submit] : "Submit")
  end
  def model_field(type, obj_field)
    assert_field @form_url, type, @model_obj, obj_field
  end

Used as:

  assert_form '/users/login', :user, :submit=>'Log-In' do |f|
    f.model_field :text, :username
    f.model_field :password, :password
  end

Relative to ryanb's post, the name of the model is currently a "full" parameter instead of part of the optional hash...  Not sure where I like it better.  And of course I still need to add a ton of other delegates.

However the ugliest part of the prototype is the binding the assert_form parameters to instance variables and yielding self.  I've been trying to dig through the rails source to see the idomatic way of handling this (create table migration, etc)...  I'm assuming I'll probably want to create a new class, that mixes-in the assertions I want and that takes these parameters in its constructor.  Does this sound ruby/rail-ish?

That worked and feels clean enough to me to go on, so I'm pulling the code out from the single test case I've been testing it in and moving it to the test_helper series of files.  Thanks.

Now that it looks cleaner I'll try to explain the other (minimal) repetition that is bothering me more than it probably should.  I'm probably being too picky here....

Given a test case like:

class UsersViewTest < Test::Rails::ViewTestCase
  def setup
    super
    assigns[:user]=User.new
  end
  def test_sign_up
    render
    assert_form '/users/sign_up', :user, :submit=>'Sign-Up' do |f|
      f.model_field :text, :username
      f.model_field :text, :email
      f.model_field :password, :password
      f.model_field :password, :password_confirmation
    end
  end
  def test_login
    render
    assert_form '/users/login', :user, :submit=>'Log-In' do |f|
      f.model_field :text, :username
      f.model_field :password, :password
    end
  end
end

You can see two remaining duplication smells, one of which I think is benign, the other less so.  The acceptable duplication, to me, is the inclusion of the username and password in both tests.  While it possible to do some something like

  def test_sign_up
    render
    assert_form '/users/sign_up', :user, :submit=>'Sign-Up' do |f|
      shared_fields f
      f.model_field :text, :email
      f.model_field :password, :password_confirmation
    end
  end
  def test_login
    render
    assert_form '/users/login', :user, :submit=>'Log-In' do |f|
      shared_fields f
    end
  end
  protected
  def shared_fields(f)
    f.model_field :text, :username
    f.model_field :password, :password
  end

I think that hides the details of the form in a non-useful way.  I probably would use this technique if I was testing dynamic (AJAX) forms where there are some "constant" fields and others that come and go based on selections -- in that case you want the test to focus on the changes/deltas.  In this case though, I don't think people view the login form and the account creation form as derivatives of each other.  Your thoughts?

The duplication that does bother me, however is that darn 'render' that kicks off both test methods and can't be moved to the setup (as setup doesn't have access to the test method name and therefore can't do its magic method_name->view file lookup).  Due to testcase (fixture in most xUnit but not Rail's fixtures) refactoring, most/all of my assigns happen in the setup and thus there's 'nothing' to customize aside from the view to request and that could be handled by magic.  (A similar arguement exists for controller tests with the initial get/post.  However in that case there is the decision of which get/post is needed as well as the requirement to pass arguments to the controller which would limit the refactorings, even if controller tests had similar "magic" as view tests.)

I'd love to get rid of the requirement to call render (while at the same time reserving the ability to call render with parameters when needed).  The only approach I've thought of so far would be to hack into ViewTestCase (and possibly into the assertions in action_controller/assertions.rb and the code in test_process.rb) to do a lazy-load (if needed) for @response.  Ie,

  if @response.body.nil? render

I might be able to do this with a simple method rename/chain.  Of course it'll need to tweak render's rules to look up the callstack (if possible?) to find the first method with a method_name like test_* as opposed to the immediate caller.

Thus if no render was explicitly called a parameter-less render would be inserted before the first assertion; otherwise whatever explicit render was called would be respected.

Is there a simpler way?  Is this even worthwhile or am I chasing shadows here?

Actually this kinda brings me back to an earlier issue I've had with Test::Rails -- I'm not too happy with how view tests use the method_name magic and controller test don't.  I'd expect them to both work the same, ie render <template_name> and get/post <action_name> or "bare" render and get/post.  The magic view template method_name look up feels like my proposed second refactoring -- it removed the duplicated (method_name and template) but at the expense of lessened clarity.  Of course I guess I can choose not to use the magic and use explicit templates in my calls to render.... and thereby be less contrained on test method naming.