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.
"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.)
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 ;-)
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..."
It depends on your perspective. Vagrant is billed as a manager of development environments. It has a well known and easy to use workflow for creating/modifying/destroying those environments (vagrant up/provision/destroy). With its Docker integration, it provides you with a nice management layer for managing those Docker development environments. You could achieve the same thing with Docker directly, but there would be some non-zero amount of work required to create your workflow commands and share that development environment with others (whereas with Vagrant you just need to share a Vagrantfile).
Here's an interesting Stack Overflow question related to this topic, http://stackoverflow.com/questions/16647069/should-i-use-vag.... Also, it looks like Docker is working to build out its own development environment tools using Fig, but that seems a bit nascent right now.
As mentioned in the article, Vagrant actually comes with built-in support [1] to run Docker containers. Ideally it would obviate the need to do some of the manual work done here to get this type of environment up and running.
The Vagrant support for Docker uses boot2docker, which only supports VirtualBox, so I’m left high and dry.
You can use a proxy Vagrantfile to configure the type of machine that is used as the Docker host [2]. Unfortunately there is a bug [3] that make this not quite usable yet.
As another example of using genetic algorithms for breaking things, a friend of mine wrote his dissertation [1] on using genetic algorithms for file format fuzzing. I believe there may even be some source code available on GitHub.
That exact use case is not currently possible, but it's something we've talked a bit about. We're still considering doing something like it in the future.
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...