Hi, I have been playing some more with selenium v2.0.0 after the maven artifacts was released. It haven't been too bad, the new WebDriver API is really nice and the WebDriverBackedSelenium is a decent replacement for selenium1, but I think there are a couple of minor kinks that the selenium team has to look at before its really ready for some serious business.
For instance it seems that selenium2 has problems with clicking a link that contains a ":" (component event) thing in the "DynamicTests" - the "click" part seems to work, but detecting when the page has loaded screws up - doing a "get" on the same url as the link uses works, so its probably just a minor issue. I want to discuss this issue with the selenium guys, but haven't had the time yet ;) As for performance: Running 1300+ of the tapestry-core tests takes around 12-15 minutes on my windows7 laptop (running from my 5400rpm drive, not the ssd) IIRC. (1000 of the tests being non-selenium tests and they does not take much of the time). I can't remember how fast selenium1 was on the tapestry tests as it has been ages since I've had firefox3 installed. To be honest the most annoying thing about the automated tests isn't that they run slow, its the lack of the possibility to specify which tests you want to run from the command line IMO. I have to hack around in testng.xml to minimize the scope when debugging the test-cases as I haven't found any way to get the gradle -Dtest.single=xxx stuff working. Its a total waste of time/a risk of introducing errors having to hack things like testng.xml to simply get that single interesting test class to run. I have a feeling that the webapp integration tests possibly should go into separate source sets and the testng.xml may be dumped in favor of relying on gradles automatic test detection, but my gradle-fu isn't really strong enough to test this thesis out quickly. But I think this segmentation of the integration applications (which is done in testgn.xml today) will making with the -Dtest.single (and the other built-in gradle stuff) play much nicer. I think I'm pretty close to having the core test-suite running to completion (without having to rewrite insane amounts of test-code) - I can give it a go when i get home from work today. My personal opinion on a selenium switch is that is has to be done as selenium1 requires ancient browsers. But backwards compatibility should be a priority (as a complete rewrite of the current tests probably will not bring much extra value except for possibly increased test performance) - I think a better test segmentation would go a long way to address the performance issue. Also there are probably many applications out there with comprehensive test-suites based on the current SeleniumTestcase (selenium v1 api) that would be stuck with the old selenium crap or forced to rewrite everything. (A documented upgrade path to selenium v2, mentioning the most common patterns would probably go a long way towards making this relatively painless ;) Btw. the possibility of starting the integration test apps using the JettyRunner from ones IDE should probably be mentioned somewhere, it is a nice feature! (alternatively it would be really nice to be able to run the test-apps from command line if possible). If someone knows the command line magic to run a single test / a group of specific tests please enlighten me! ;) -- Chris On Mon, Jul 18, 2011 at 11: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] > >
