WebDriver Support in Safari 10 | Hacker News Reader

WebDriver Support in Safari 10

webkit.org

182 pointsokket35 comments

This looks really great. Baking in support for test automation seems like a no-brainer and a welcome step forward for web development.

Are any other major browsers taking a similar approach to Safari in terms of native WebDriver support? I saw this Microsoft blog [1] on Edge support of WebDriver, but it's not clear to me what approach they have taken (you still need to download a separate server for instance).

Only one Safari browser instance can be running at any given time, and only one WebDriver session can be attached to the browser instance at a time.

One downside to this approach is that it limits the ability to parallelize tests on a single machine for efficiency purposes.

1. https://blogs.windows.com/msedgedev/2015/07/23/bringing-auto...

Does that limit multiple tabs/windows? I would assume that a browser instance is a collection of multiple window contexts.

Both Chrome and Firefox already support WebDriver. They both allow tests to run in parallel by opening multiple windows.

"Are there any other major browsers taking a similar approach to Safari in terms of native WebDriver support?"

Let me tell you about the "world domination plan" for the Selenium project. In the beginning of the project, no browser had a good automation story. It was a constant battle to catch-up and fix things every time a new browser version came out. With Selenium 2, in addition to merging in WebDriver, the grand strategy was to move the maintenance of each browser driver codebase to the browser vendors themselves. Opera, Mozilla, and Google quickly jumped on board with the idea. To further this strategy, we moved Selenium's IP to a neutral 3rd party (Software Freedom Conservancy), and worked towards a W3C browser automation spec that looks suspiciously identical to the WebDriver API. Now with Microsoft and Apple also on-board, we can all raise our glasses and yell "Cheers!"

Of course, there's no rest for the weary. The battleground for good test automation tooling has now shifted from desktop to mobile (and possibly TVs, cars, watches, IoT, etc.)

I wonder... Boss - "I see you expensed a Tesla" Me - "Yes, its for browser testing..."

You kid, but at some point over the years, I had that same epiphany: If you want a built-in justification to play with any new toy, pursue a career in test automation! (I don't have a Tesla, yet, but I'd be happy to be invited over to the test track to talk shop... But seriously folks... I'm very curious how they test the software running on their dashboard and center console.)

Google's advice was always emulation--the tests running on dozens of Dell servers were faster and more reliable at bug hunting than physical hardware. Obviously there are limits, but the advice in 2013 was to prioritise automated tests in simulators instead of on real devices. Note the emphasis on automation, though -- you can totally expense that Tesla for the manual/acceptance testing ;-)

Emulation, and specifically domain modeling, goes a wicked long way and has huge speed advantages in general.

"But couldn't you run it in a VM?" ;-)

Then again, I can't actually find a VM for QtCarBrowser... short of downloading an old version of QtWeb presumably...

This is why there's a market for robots for testing -- real robots hitting real buttons. Especially in the automobile industry, no company wants to be hauled in front of the oversight committee in Congress after some horrible accident and when asked how they tested everything, they're only able to say "Well, all the tests passed in the simulator, so we went straight to production..."

This is fantastic news!

The blog post doesn't mention iOS. Does anybody here know whether iOS Safari 10 will also support Webdriver?

According to the docs: yes. https://developer.apple.com/library/prerelease/content/relea...

Where are you seeing that? I'm seeing:

>Safari on OS X supports WebDriver, which lets you automate web-content testing. It provides a set of interfaces to manipulate DOM elements and control the browser’s behavior. You can enable Remote Automation in the Develop menu and then launch the server using /usr/bin/safaridriver. For information about library integrations as they become available, see the information about Selenium WebDriver.

Notably, the "on OS X" bit. (Shouldn't that be on macOS? I thought "OS X" was done for!) Equally, you obviously can't launch the server using /usr/bin/safaridriver on iOS.

From article: "Starting with Safari 10 on OS X El Capitan and macOS Sierra, Safari comes bundled with a new driver implementation that’s maintained by the Web Developer Experience team at Apple."

Sorry guys, you're right. It's a bit confusing that Apple doesn't state clearly at all of the new features whether they're iOS / macOS-only.

From the link you shared:

> Safari on _OS X_ supports WebDriver, which lets you automate web-content testing.

I don't see any mention of iOS in relation to WebDriver.

Too late to edit my post, but I asked @brrian on Twitter and he said "no," iOS Safari 10 will/does not support Webdriver. https://twitter.com/brrian/status/769269326897557504

It's a good thing but they are really late to the party in supporting Selenium.

ensuring a good user experience across multiple platforms and browsers is a huge challenge for web developers and QA organizations

It's a shame we've been fighting this battle since the 1990s and are still fighting it.

Why would this be an easy battle? Creating design and code that works on billions of devices, on independently-developed browsers for multiple operating systems, viewed through wildly-varying physical dimensions and I/O, seems like it's one of those battles that would seem to be perpetual.

welp, scrapers rejoice

Now if we can only get tabs to suspend themselves to free up RAM. Safari is awesome to work with, for the first hour.

For me, Safari runs for weeks at a time with several hundred tabs open.

Indeed, Safari is the only browser that doesn’t render my machine unusable under such use. (Both Chrome and Firefox seem to consume dramatically more CPU and memory for the same load.)

What kind of situation are you running into where it stops working after an hour?

How much memory do you have on your machine?

2008 MacPro 2 x 2.8Ghz Quad-Core Xeon , 28GB RAM, drives are SSD.

Just keep tabs open, they eventually start chewing up hundreds and hundreds of MB of ram each, and slowly grinds itself into the ground. Relaunch, it's snappy again.

I wonder if it's something those sites are doing in JavaScript, because I have the same experience as the other poster. I keep tabs in Safari open for weeks at a time without any issue or noticeable memory increase.

However, I do know there are a handful of web app type things (Google calendar and possibly Gmail are coming to my mind) that seem to leak memory and cause issues if left open.

Edit: eridius mentioned Google Docs. I'm pretty sure that's what I was thinking of.

Virtual memory should be handled by the operating system not re-implemented by each application.

Are you by any chance leaving Google Docs pages open for a long time? Safari runs great on my machine, with windows and tabs open for weeks at a time, and the only problem I ever have is with Google Docs, because Google Docs is a gigantic memory hog. If I leave a Google Docs page open for a day, it usually ends up consuming several gigabytes of memory all on its own. For a company whose focus is the web, I don't know why Google can't get their memory usage under control.

(Caveat: I haven't actually tried leaving a Docs page open for a day in a while. I stopped doing that when I discovered how badly it behaved. It's possible Google's fixed it, though I doubt it)

Negative on Google Docs.

I don't see this either, but I don't have Flash installed. Could that be the culprit?

I haven't had flash installed for a couple years.

I have the same Google Docs issue; it can bring my machine to its knees. I open anything Google in Chrome, and the rest of the web in Safari. Without Docs, Safari is as solid as a rock. Google Docs seems to run fine in Chrome.

Part of me is thrilled by anything that makes validation easier. Part of me is frightened by the expansion of the attack surface of the browser, particularly given how Apple has been losing their quality edge of late.

The blog post notes that the Safari that is driven by the automation cannot interact with other windows or user preferences. It also requires that the user has had the "enable remote automation" enablex, which is only possible if you have enabled the developer menu bar.

In addition, automation windows are shown with a different coloured bar and have a "pane" over the window so that it won't receive stray mouse or keyboard input.

> particularly given how Apple has been losing their quality edge of late

I know this is a subjective opinion and I'm not going to touch upon whether I think it's true or not, but I want to know why you even said this bit? The common claims about Apple's quality slipping don't have anything to do with security. If anything, Apple's security is getting better and better over time.

It is very noticeable that their software quality is dropping. It is parsimonious to assume this will impact complicated API surfaces negatively.

Reply on news.ycombinator.com