Our team was recently benchmarking using Mechanize vs Selenium::Remote::Driver for a basic request pattern:
- get a page - check the title - check the body content I expected Selenium to be slower, but was surprised it was about 8 times slower! As I look more closely at the inner workings, what was going on became more clear. Mech makes one request, and uses the cached content to check the title and content. Meanwhile, it appears the Selenium protocol dictates that 3 requests are used: 1. Instruct the driven browser to load the page. (1a. The browser actually makes the request) 2. Ask the browser what the title of the page loaded is. 3. Ask the browser for the page source (or ask it to find an element in the DOM on your behalf. It seems like some considerable speed gains might be made with some kind of hybrid approach-- something that involved sometimes caching the page source locally, and querying it multiple times locally, rather than getting one HTTP request to the browser for each query. For now, we are sticking with an approach of "Mechanize when we can, Selenium when we have to". How are other people improving the performance of functional browser teesting? I realize there are some non-Selenium solutions out there, but I like the ability to take advantage of services like Sauce Labs, which provide parallel Selenium testing in the cloud. Mark