Mike H. wrote:
some of the support for it in Selenium (i.e., waitForElement etc.).
So far we have found Selenium to be pretty good. Documentation can be
sparse and the Selenium IDE Firefox plug-in is great at getting you
started, but you typically need to mess with the Ruby it poops out. We
are using RSpec rather than Test::Unit (Selenium poops out tests in
Test::Unit format) so we have to convert them which isn’t too awful, but
can be tedious.
T. Alexander Lystad is posting this on behalf of Jari Bakken:
haven’t done any extensive testing yet, but one of the deciding factors
for choosing HtmlUnit was their commitment to this feature.
the configured browser (Firefox or Internet Explorer). It uses the Rhino
bugs) and provides the implementation for the objects specific to the
execution in a browser.
are well supported (the unit tests of some well known AJAX libraries are
where currently most of HtmlUnit’s development activity occurs. If you
encounter a problem it may be already have been fixed since the last
release. Otherwise, don’t hesitate to open an issue with an example of
So we think this shows good promise. Celerity provides access to the
underlying HtmlUnit objects, so you can make low-level calls to HtmlUnit
if needed, or we can add stuff to Celerity’s API for common operations
(as soon as we discover them ;). Alternatively, Celerity is compatible
with Watir, so you should be able to run your tests with Watir if
HtmlUnit can’t provide the same functionality.
Mike: I tried Selenium IDE a while back, but wasn’t really happy with
how it identified elements (long XPaths, etc). A recorder also requires
that you already have an implementation of the functionality you’re
testing - so you’re not doing test/story-driven development. We have a
domain-specific abstraction layer above the actual Celerity/Watir calls
anyway - so test developers can call methods like OurSite#login,
#navigate_to(…). A recorder isn’t really useful in our situation.
To unsubscribe from this list, please visit: