Colin Law wrote:

> I think I have not explained myself adequately. I have no problem with
> points 1 and 2 - the test and the implementation for the action invoked
> when the remote call is made. It is point 3 that is the problem. How
> do I write the test for the link_to_remote placement unless I know the
> form of the html that link_to_remote generates?

Here is a bit of hemming and hawing, while I work on projects other than
assert_xhtml and assert_rjs_ (as seen at http://c2.com/cgi/wiki?AssertXhtml )

TDD (aka BDD) works best on greenfield projects - ideally on platforms which
were themselves invented via TDD. Such projects will have assertions matching
each feature, ready to use. You simply alternate between writing assertions and
writing code statements.

> I know the URL but not
> how the div and url appear within the Ajax.Updater javascript call. In
> principle I do not even know that there is an Ajax.Updater call, nor
> whether I need to check any of the other parameters of the call.

When TDDing into a legacy system, especially a View, expect to cheat early and
often.

Write the test up until the point where you have no assertion, then fudge it.
Assert that your <a onclick> matches 42, for example.

Write the code you want, get the assertion to fail, and look at the diagnostic.
Copy its relevant details into your assert_match, and keep going. A change in
the RJS library might someday break your assertion; you don't care.

The _next_ time you TDD an <a onclick>, clone that assertion and upgrade it. You
will soon discover an application-specific assertion pattern which might work
for all Ajax in the world, but will tolerably propel your own project.

My assert_rjs_ is teetering on the brink of doing this:

a = assert_xhtml{|x| x.a.my_id! }
assert_rjs_ a[:onclick], :remote_function, :url => { :action => 'yo' }

However, these days I am shamelessly earning money instead of working on it.
Sorry! (-:

--
Phlip
http://flea.sourceforge.net/resume.html