On Mon, Jul 18, 2011 at 4:53 PM, Howard Lewis Ship <[email protected]> wrote: > Howard said: > My experience is that using the old Selenium APIs with WebDriver 2.0 > is about 100% slower (i.e., execution takes twice as long).
I was able to duplicate this. I made some changes to SeleniumBaseTest to use WebDriverBackedSelenium instead of DefaultSelenium. The tapestry-core tests take 14 minutes on a machine where using 2.3.1's native selenium calls (which is what the code in trunk is doing now) only take about 7.5. However, if you use HtmlUnit instead of Firefox, it only takes 1 minute and 20 seconds! DefaultSelenium (using 2.3.1) - This is what is currently being used in trunk. It runs about as fast as selenium1 and lets you use current versions of FF and Chrome. Maximum compatibility with the older Selenium API. There doesn't appear to be a way to use HtmlUnit with this. WebDriverBackedSelenium - Lets you use current browsers, plus HtmlUnit. Can switch back and forth between Selenium and WebDriver Api so all the existing tests would be compatible with it. Reasonable compatibility with older Selenium API. (It looks like tapestry-core has 6 tests that would need to be modified.) It is about twice as slow as using Default Selenium. This is basically a stop gap measure to help people migrate and not something that should be used if it can be avoided. WebDriver - Supports most modern browsers and HtmlUnit. Completely different API. Should be significantly faster than WebDriverBackedSelenium and potentially faster than DefaultSelenium. > Kalle said: > Well, they could just use an older version. But for Tapestry, it'd be > very valuable if we could retrofit the SeleniumTestCase to use > WebDriver api so we wouldn't need to scrap or rewrite all the existing > tests. I have a version of SeleniumTestCase as you described that I'd be happy to clean up and contribute, but it is slow with FF. What is in trunk right now gives the maximum performance in UI based browsers without rewriting tests. I also have a partially working WebDriverTestCase that works like SeleniumTestCase, but uses the WebDriver api. If there is interest, I'd think I can implement the following: SeleniumTestCase - Basically what is in trunk now, but possibly extracting the interface out of it. WebDriverBackedSeleniumTestCase - Existing tests could be switched to extend this and they would still run although slower than when extending SeleniumTestCase. This would allow individually switching unit test by unit test to the WebDriver api without breaking the entire build. It would also allow running HtmlUnit tests by specifying it in testng. As far as I know, doing this with HtmlUnit is the fastest way to run the tests without moving away from the Selenium API. WebDriverTestCase - Once a WebDriverBackedSeleniumTestCase was switched over to use the WebDriver api, it could be set to extend WebDriverTestCase to get the speed increases of using native WebDriver. Now if the plan is to throw out SeleniumTestCase and switch all the tests to Geb, this probably doesn't make sense. If the plan is to provide some level of support for Geb, but keep the existing tests on SeleniumTestCase, then maybe it makes sense to just create the WebDriverTestCase for people wanting to use java and the WebDriver api. If any of what I've described sounds useful, let me know and I'll submit a patch for consideration. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
