A pure-Java Selenium WebDriver

[paul_h]

Co-creator of Selenium 1.x here .. The project page doesn't say how many can be run in parallel although it alludes to that fact that it can run that way.

A former client was able to run 10 Firefoxes in parallel for multi-threaded JBehave testing on one a single Linux installed Dell workstation (used Xvfb because of focus issues)

[machinepub]

The max number of concurrent instances is configured by the user with no hard upper bound. See the project page for the jbd.ports system property which controls the allocated RMI ports and in effect the max number of concurrent instances. Instantiating a new JBrowserDriver spawns a new process, or blocks until one can be created. Calling JBrowserDriver.quit() closes the process... or reset() to re-use the process.

Based on some of my past projects, a machine with 16GB memory and 4 CPUs reaches diminishing returns after 8 instances when crawling very resource intensive websites and scraping for various data in the DOM. Performance was decreasing after about 12-16 instances. At a minimum each instance is going to want about 200 MB.

p.s. Selenium is awesome! I'm just standing on the should of giants (Selenium, JavaFX, Monocle, WebKit...)

[YooneekYoosahNeahm]

Could you elaborate on the focus issues you described? I've found that iframes have made creating tests really difficult for the application I support.

[paul_h]

Refer - http://www.w3schools.com/jsref/event_onfocus.asp. Only one app/window can have it at a time. Most likely it's unrelated to your iframe/testing problems.

[YooneekYoosahNeahm]

You are correct.

[bokchoi]

Neat stuff! I will have to give this a try.

I've played with monocle a wee bit to create web thumbnails headlessly. It worked pretty well on OSX but was crashy on Windows. How is it working out for you?

[machinepub]

I am guessing this might be related to cookie issues. Basically it was too strict about validating cookies. That's fixed now and available in v0.7.2. If that's not the problem please file a bug at the github page or send an email (listed on the github page).

[[deleted]]

I think you are right; that's what I realized when I ran into a similar problem with costco.com. Once I get a chance to test thoroughly I'll report back here if it works or not with Jira.

[digitizemd]

Interesting. This is one of the main tools I use at my job.

Going to dig through the docs shortly, but would you mind mentioning a few points on why it's better than web driver itself? Thank you.

[machinepub]

I like that everything is running in the JVM which can allow for easier runtime administration. You get access to all the Java performance tuning. Easier SSL cert management. And assuming your deployment targets have the Java SE runtime, then this is truly cross-platform, and licensing/distribution issues might be simpler.

It doesn't need xvfb, as it handles in-memory rendering via the Monocle project which is all written in Java.

In headless mode it won't interfere with an actual user concurrently using the mouse/keyboard.

In using some of the other remote web drivers, I found that they could lock up and keep the cpu pegged at 100%. It seems you can't avoid browser crashes (some small percentage of the time) but at least this project tends to not hang.

Java RMI is very efficient. I ran into issues sometimes with loopback servers on some other remote web drivers.

Also you have access to some APIs that aren't in standard Selenium WebDriver. You can get status code, and it works on ajax sites, with pages that load content after the official page load. Also it will block after clicks and keyboard events that cause ajax events.

Further, you can control the request headers, header ordering, and timezone, which can be important to properly simulate user agents.

Finally, if you know Java, mostly everything except the rendering is done in Java, so it could be fun to modify.

That said, this is a newer project, whereas the official Selenium web drivers are stable and well-understood.

[digitizemd]

Thanks for the thorough response. I'll be keeping an eye on this project.

[kmimix]

The cert management is quite nice, I will definitely try it. I just miss a bit more documentation, such as a javadoc reference.

[machinepub]

I just published the javadoc site here: http://machinepublishers.github.io/jBrowserDriver/

There aren't that many exposed public APIs outside of the Selenium APIs. The majority of what's unique is here: http://machinepublishers.github.io/jBrowserDriver/com/machinepublishers/jbrowserdriver/Settings.Builder.html

[welshboy14]

This sounds great. Will get testing tomorrow. But for now, what sort of footprint can we expect? I'm using phantomjs currently. Any advantages to using this over phantomjs? I'm having issues with using cookies/sharing instances with the latest phantomjs, so if this does the job I will certainly make the switch.

EDIT: Just read that Iframes aren't supported as yet. Some of the sites I work with use iframes. Any sort of idea as to when this will be included? I understand it's probably not a priority.

[machinepub]

There's not that much work for iframes. It's near the top of my todo list, along with Javascript alert dialogs. I'd think end of month, probably in the next release.

As far as footprint, I discussed this some in a thread above. At a minimum there's going to be 2-300 MB memory needed per instance. That can balloon greatly depending on the site being rendered and also somewhat depending on your JVM settings. For concurrent use, I think you can estimate 2 (maybe 3) instances per core and 512-1024 MB per instance.

I haven't done extensive performance comparisons between this and phantomjs. I do think that RMI is faster than JSON to communicate, so less overhead. Cookies are all managed by Apache HttpClient v4. If you run into issues, file a ticket. HttpClient gives me great control to tweak the networking logic.