Alister => thanks, will look into that, but I think it's prudent not to wait for the 'perfect' headless driver ...
Simon => understood ... and will comply =) I guess in planning this out though it would be nice to have contingencies, such as side stepping HtmlUnit when the need arises. Best way I can think of is extending relevant classes (net/http? httpunit?) or sidejacking the user session/cookies ... I'm thinking this may be my first test case [to reduce] http://stackoverflow.com/questions/4995393/tests-using-webdriver-with-remote-htmlunit-having-redirect-issues-when-logging-in Cheers, Tim On Tue, Feb 15, 2011 at 12:02 PM, Simon Stewart <simon.m.stew...@gmail.com>wrote: > I know of teams that have done some fairly advanced testing with the > headless webkit driver. It can be pretty good. I also know that the > developers love a good bug report with a reduced test case > highlighting any issues ;) > > Simon > > On Tue, Feb 15, 2011 at 8:49 AM, Alister Scott <alister.sc...@gmail.com> > wrote: > > Hi Tim, > > > > I have spoken about the Rhino limitation in htmlunit with Jari before > (which > > IMO makes WebDriver headless unusable), and he pointed me at webkitdriver > > (http://code.google.com/p/webkitdriver/) which looks like it'll be a > > replacement for htmlunit. > > > > I don't know how far away webkitdriver is from the primetime, but I > imagine > > Jari might be able to provide some info on it. > > > > Cheers, > > Alister > > > > > > Alister Scott > > Brisbane, Australia > > Watir Web Master: http://watir.com > > Blog: http://watirmelon.com > > LinkedIn: http://www.linkedin.com/in/alisterscott > > > > "There are two ways to get enough: One is to continue to accumulate more > and > > more. The other is to desire less." ~ G. K. Chesterton > > > > > > On Tue, Feb 15, 2011 at 9:17 AM, Tim Koopmans <tim.ko...@gmail.com> > wrote: > >> > >> Hi guys, > >> I've been putting more thought into load testing and what that means for > >> Watir. Watirgrid allows for distributed testing across a grid network, > but > >> it is heavy in the sense of 1 core = 1 browser. So a 1000 user load test > >> means a lot of cores spun up on EC2 or the like ... > >> WebDriver seems the right direction for me. I've since added webdriver > >> support to watirgrid, and am really interested in capabilities of > >> htmlunit. I can easily spin up say 100 threads per core using htmlunit > with > >> no obvious degradation to performance. It's not the perfect world > >> (especially with Rhino) but it's a good start. > >> I know others have thought about this and experimented a little. One of > >> the traps I see in this approach is htmlunit itself, or rather Rhino. If > the > >> application under test has some weird JS combo not executable by Rhino > then > >> the test case is stuck. > >> It would be good if we could gracefully downgrade to a lower (protocol) > >> level if needed. For example if the test case got stuck executing within > >> htmlunit, we downgrade to httpunit or net/http and make the request > needed > >> to get past manually. Has anyone experimented with this before? I was > >> thinking of perhaps hijacking the session (dumping cookies from Watir, > >> re-using them with net/http if possible) > >> Jari also suggested extending HtmlUnitDriver but I'd most likely need to > >> be doing this in Java (maybe via JRuby) to get this working ... > Thoughts? > >> I'm really keen to get some movement in this space (load tests with > Watir, > >> one test API for functional _or_ performance automation etc) and would > love > >> to talk about this with anyone else interested at Watir Day (SeConf). > Other > >> areas of interest are tying Watir in with other performance monitoring > tools > >> (like splunk, dynatrace, fiddler, webtiming etc). I think I'll pursue > with > >> Watirgrid until it makes sense to split out otherwise. > >> > >> > >> > >> Cheers, > >> Tim > >> @90kts || watirgrid.com > >> _______________________________________________ > >> Wtr-development mailing list > >> Wtr-development@rubyforge.org > >> http://rubyforge.org/mailman/listinfo/wtr-development > > > > > > _______________________________________________ > > Wtr-development mailing list > > Wtr-development@rubyforge.org > > http://rubyforge.org/mailman/listinfo/wtr-development > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development >
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development
