On Thu, Aug 11, 2011 at 5:53 PM, Mark <[email protected]> wrote: > By the way, the current patch will only switch to the newer version of > selenium. It does not use WebDriver which is what would be necessary > to use HtmlUnit. > For that to work, we need to replace the old setup in SeleniumTestCase: > > final Selenium selenium = new DefaultSelenium(commandProcessor); > > With something like: > > final WebDriver driver = new FirefoxDriver(); > final Selenium selenium = new WebDriverBackedSelenium(driver, > baseURL); > > It would probably make sense to set things up so testng.xml can > specify FirefoxDriver, HtmlUnitDriver, etc. > > This should let us run all the tests without an issue in theory, but > in practice there may be a few that will need to be tweaked as > WebDriverBackedSelenium emulates DefaultSelenium, but not perfectly. > > Once you have an instance of WebDriverBackedSelenium, you can get the > WebDriver to use that API using: > WebDriver driver = ((WrapsDriver) selenium).getWrappedDriver(); > > I've been working on a patch for SeleniumTestCase that will do that > but I'm running into problems getting selenium to start without > conflicting with the existing code. I wonder if it wouldn't make more > sense to do something like WebDriverTestCase.
And I wonder if it wouldn't make sense to scrap SeleniumTestCase and all that, and just have people do something sensible, like use Geb. > > Mark > > On Tue, Aug 9, 2011 at 12:43 PM, Kalle Korhonen > <[email protected]> wrote: >> >> Mark, this is very useful. I continue to be a firm believer of >> htmlunit (see e.g. >> http://docs.codehaus.org/display/TYNAMO/2010/07/30/) because >> HtmlUnit-based functional tests simplify the testing environment and >> running them within the IDE, and also because they run much faster >> than the Selenium (1) tests. Using the WebDriver could improve >> execution speed and Selenium 2 also allows using HtmlUnit as the >> WebDriver (although it's somewhat questionable what the extra >> abstraction layers buy you in that case). It would be an interesting >> exercise to rewrite some tests to use the WebDriver and compare >> execution times of different drivers, namely against HtmlUnit. >> >> > I've attached a patch in case anyone wants to test it out. I filed a JIRA >> > issue TAP5-1599, but for some reason I can't seem to upload an attachment >> > to >> > JIRA. >> >> Is the patch really big? There may be a file size limit. >> >> Kalle >> >> >> > On Mon, Aug 8, 2011 at 5:48 PM, Mark <[email protected]> wrote: >> >> I ran some tests on Ubuntu Linux using Firefox 3.6. To run Selenium >> >> 2, I changed the dependency in tapestry-test and added a method that >> >> was required by the new interface. If there are two test times >> >> listed, I ran the test twice. >> >> >> >> Here are the results: >> >> >> >> 5.2.6 Selenium 1 & Maven >> >> 6 min 14 sec >> >> >> >> 5.3 with Selenium 1 & Gradle >> >> 7 min 5 sec >> >> 7 min 14 sec >> >> >> >> 5.3 Selenium 2.3 & Gradle >> >> 7 min 26 sec >> >> 8 min 1 sec >> >> >> >> So in my tested configuration, a switch to Selenium 2.3 doesn't add >> >> any significant amount of time to the build as long as you stay on the >> >> browser that today we are forced to use. It might be slower on newer >> >> browsers, but that isn't a fair comparison because we can't use them >> >> right now anyway. >> >> >> >> >> >> Mark >> >> >> >> On Mon, Jul 18, 2011 at 4:53 PM, Howard Lewis Ship <[email protected]> >> >> wrote: >> >>> My experience is that using the old Selenium APIs with WebDriver 2.0 >> >>> is about 100% slower (i.e., execution takes twice as long). >> >>> >> >>> On Mon, Jul 18, 2011 at 1:40 PM, Mark <[email protected]> wrote: >> >>>> It looks like Selenium 2.0 can run using WebDriver where it directly >> >>>> works with the browser or emulating the older Selenium RC approach. >> >>>> Is WebDriver slow or is it when you try to run 2.0 using the older >> >>>> style tests? I thought part of the point of WebDriver was to be >> >>>> faster. >> >>>> >> >>>> Mark >> >>>> >> >>>> On Mon, Jul 18, 2011 at 1:47 PM, Howard Lewis Ship <[email protected]> >> >>>> wrote: >> >>>>> I've been using Geb (a Groovy wrapper around Selenium 2.0) and I've >> >>>>> been having a lot of trouble since Selenium 2.0 changes things; just >> >>>>> swapping out the new code takes a huge hit on performance. I might >> >>>>> take a go at this, but I'd rather start thinking in terms of >> >>>>> deprecating the selenium support inside tapestry-test and seeing about >> >>>>> adopting Geb as a better solution that embraces Selenium 2.0. >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: [email protected] >> >>>> For additional commands, e-mail: [email protected] >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Howard M. Lewis Ship >> >>> >> >>> Creator of Apache Tapestry >> >>> >> >>> The source for Tapestry training, mentoring and support. Contact me to >> >>> learn how I can get you up and productive in Tapestry fast! >> >>> >> >>> (971) 678-5210 >> >>> http://howardlewisship.com >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: [email protected] >> >>> For additional commands, e-mail: [email protected] >> >>> >> >>> >> >> >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
