Hi Jonny,
The advantage I see to selenium is that it in combination with the
selenium ide,
functionality tests are a whole lot faster to write, than the
traditional tests.
I click on record in the selenium ide, interact with my app to test a
specific feature (or sequence). When I want to assert a specific element
is present (or not) I use the xpath checker to get a specific handle to
the dom element.
At the end of the session, my functional test is ready for me and I’ve
done very little typing (just a few clicks). I can now modify it if
needed.
I’d start by generating the test with script/generate selenium
test_name, open that test in the ide and click away.
The way I see it, testing the controller mostly involves testable
changes in the UI. Testing the business logic usually occurs in the unit
tests for me. I use the functional testing to make sure the UI is
responding the way I expect it to, so why use the traditional functional
tests for that when you can use selenium.
I can imagine testing things like action mailer with the traditional
functional tests but little more.
I imagine Selenium to be like my end user, beta testing my app.
or am I missing something? 
Jonathan V. wrote:
I was thinking about that same question recently.
I decided to slim down my functional tests to only test the logic of the
controller. If an action is supposed to update/save/add records, I will
have a functional test to ensure that the action works correctly, and
that records are saved/updated in the database. A Selenium test will
check that the correct parts of the page are updated and/or the user is
redirected appropriately.
Basic idea: no assert_tag calls in functional tests! Only test the
business logic of each action.
BTW: I have got my own Selenium testing plugin, which lets you write
Selenium tests in the same way you write functional/unit tests. It’s a
bit rough, but check out
http://blog.viney.net.nz/articles/2006/02/09/selenium-testing if you’re
interested. You end up writing tests like:
class PersonSeleniumTest < Test::Unit::TestCase
selenium_test
fixtures :people, :notes
def test_view
p = people(:bob)
open "/person/view/#{p.id}"
assert_element 'name'
p.notes.each do |note|
assert_element "note_#{n.id}"
end
end
end
I like this approach because it gives a consistent way of writing tests,
the plugin definitely needs tidying up though.
-Jonny.