>>Tony Voellm: So our next speaker up is Ken Kania, he is from Google, and he is going
to talk about WebDriver for Chrome.
So with that, have fun.
>>Ken Kania: Thanks, Tony.
So to start off, my name is Ken.
Just a little bit of background, I work on the Google Chrome testing team, particularly
on just the browser side.
So a little bit about of background about how Chrome testing is broken up just real
quick.
There's the browser team, then there's kind of the mobile team and then there's the OS
team.
So I am primarily on the browser side.
Okay.
So basically I'm going to be talking today about a tool that we have supported within
the Chrome team which is called ChromeDriver, or also called WebDriver for Chrome.
So you can see up here, it's a very simple problem.
Many of you are probably familiar with it, maybe even familiar with the tool.
So we have in Chrome, just Chrome, over 300 million active users.
This is pretty old, old data, but at least that still holds true, hopefully.
So we have an ever-expanding amount of platforms.
So of course we just started with Chrome, with Chrome for beta on Windows 2008, expanded
to other desktops, now Mac, Linux, and then more recently, ChromeOS branch out into ChromeOS,
and then now mobile, Chrome for Android and Chrome for iOS.
So the question, the basic question is as a Web app developer, how can we or how can
I go about verifying that the critical functionality of my app works across all these different
platforms.
So this is a pretty broad question that you can look at just in browsers in general but
today, in this talk I am going to focus just in Chrome.
So within Chrome, how can I verify my functionality, the critical functionality that my app provides
across all these different platforms automatically.
So hopefully during your development process you have engaged in good unit testing, and
maybe if you're a really good diligent tester you've also done some sort of isolated component
testing.
But at the very end of the day, you want to have some guarantee that what the end user
sees and what you go through as an end user is actually correct.
And basically, the solution to this problem is ChromeDriver.
So a little bit of background.
ChromeDriver follows the W3C WebDriver working draft that some of the Mozilla guys talked
about a little bit earlier on this morning.
So because of that, it's interoperable with all the open source WebDriver client libraries,
whether it's Java or Python or Ruby, whatever fits your boat.
It is open source.
ChromeDriver is open source and maintained by the members of the Chromium project.
And Chromium, for those of you who aren't familiar, is the project that supports Google
Chrome and other Chromium-based browsers.
So for the rest of this talk, I'm just going to describe a couple of things.
Number one, how can you use ChromeDriver, what does it actually do.
Number two, what kind of work have we done to enable ChromeDriver to work not just on
desktop but also the other Chrome platforms; specifically Android in this talk.
And then hopefully I will give you a little bit deeper dive about how exactly ChromeDriver
works for you guys who are curious or maybe who want to adopt kind of similar technologies
underneath depending on what frameworks you are using.
So to start, WebDriver.
That previous slide doesn't make a whole lot of sense if you don't know what WebDriver
is.
WebDriver is a cross-browser automation API which is primarily for Web site testing.
That's what it historically was for.
Now there's more use cases, wider audiences using WebDriver but that was at least one
of the main uses and symptom is the main intention for the WebDriver, the WebDriver API.
So it's cross browser.
So this API covers, I listed a couple things there, we have browser control, (indiscernible)
user, simulate the user input, whether it's a mouse or typing, keyboard, et cetera.
And also the category I just put together is Web stuff, random Web kind of stuff, like
being able to find elements on a page, evaluate script, evaluate JavaScript, manipulate local
storage, cookies.
So that's basically WebDriver.
So WebDriver is cross-browser automation API.
And ChromeDriver is essentially the implementation of that protocol for Chrome.
Not a very difficult concept.
So just to get you a little bit familiar, for those of you who perhaps have not seen
a lot of WebDriver stuff before, here is a sample test written in Python using the open
source Python library.
In that statement we are creating an instance of ChromeDriver.
We are passing in the path to our ChromeDriver binary executable.
We will talk about that a little bit later.
Second statement is simply navigating to our test page, in this case which is Google.
Then we're finding an element in that page with the name Q. Saving a reference to that
element inside this variable search box.
We send some keys, which is just typing.
We type ChromeDriver.
We submit that form, and at this time WebDriver will then wait if there's any navigation that's
occurring because of that typing or because of the form submission.
And then we actually do the one actual test part of our test which is we assert that ChromeDriver
is in the title of the page that we have navigated to.
And lastly, of course, we just quit.
So that's a really simple page that hopefully gives you a feel for what you can do with
API.
So now how can we go about using ChromeDriver?
The thing here is ChromeDriver for desktop, for Windows, Mac and Linux has been around
for quite a long time, for over a year.
You can easily find that on our public ChromeDriver site, code.google.com/p/chromedriver.
Of course you can just search for it.
But recently, in the past couple of months, several members of the Chromium team from
Android, also from the browser side, have been working on a new version of ChromeDriver
which we just call ChromeDriver 2.
And -- Pretty creative.
So basically this is a rearchitectural of ChromeDriver to fit, to be able to span, like
I was talking about at the beginning, multiple more Chrome platforms because we want our
testers to be able to run our tests against as many Chrome platforms as possible.
So with this rearchitecture, we are able to support not only desktop, as I have listed
up top, but also Android.
So, yeah, I'm happy to announce that we do have alpha support for Chrome on Android,
ChromeDriver on Android testing with Chrome on Android.
And you can get hold of that on our Web site.
I have pushed a couple of links here that you can look at.
A couple of caveats with the Android alpha.
Currently you do need a special configuration.
You do need a Mac or Linux host connected via USB to your actual Android device.
But essentially, and there's a couple other things like you need Chrome 27, a couple more
details you can see on the site.
And basically, though, really what you need to do is specify the Android package capability
when you start your session.
And for Chrome OS and for iOS, unfortunately if you want to use that you just need to be
patient or want to contribute.
So you have to wait for that.
So how does it work?
A little bit background on how it works.
So there's mainly three components.
On the left here I have the WebDriver client which is essentially your test.
It doesn't have to be a test.
Maybe you're writing something else which uses the WebDriver library, which is available
in all those different flavors, different languages I was talking about earlier, that
communicates -- these are all processes, at least for Chrome.
So that's one process, your WebDriver client process.
And that talks to ChromeDriver, which is the tool that we're talking about in this talk,
which functions as the WebDriver server.
And that of course communicates over the standard WebDriver protocol that we've been talking
about today.
And ChromeDriver talks to Chrome, controls Chrome via rightly now two main ways, DevTools
and extensions.
So this is ChromeDriver 2.
The old ChromeDriver used a different Chrome automation API which was desktop only.
So now we're just going to talk about Chrome Driver 2.
So a little bit about DevTools and extensions for those guys who perhaps haven't heard a
whole lot about it.
So DevTools is the same thing.
You can see it easily in Chrome by just right clicking the page, going left clicking, inspect
element you will see kind of that debugger view, kind of like -- that comes up usually
at the bottom of the page, and you will see the DOM tree.
You will be able to see performance metrics.
You'll be able to see -- you can trace and see the network activity, what resources are
taking how long to load and kind of that breakdown.
So that's essentially -- that debugger kind of interfaces using basically DevTools underneath.
DevTools of course is short for developer tools.
So we're using that, and the main benefit behind using that is, number one, it's pretty
low level.
It used to be mostly implemented in Web kit which is now blink or been split into blink
but it's supported on all the platforms that Chrome runs on except for iOS currently.
You can do -- On iOS 6+, you can do DevTools but it's only officially supported through
Safari on OSX so we can't actually access that now on ChromeDriver on iOS.
The second main tool that we use or API that we use to automate Chrome is the extensions
API that Chrome comes supported with.
So, of course, many of you guys are familiar with extensions, the concept of extensions,
but they initially were meant to -- extensions were meant to modify or enhance the functionality
of the browser, and we've taken that and we've just, of course, plugged in our own customer
extensions and been able to control the browser through some of the APIs that are provided
there.
However, since extensions are only desktop only, we've relied mostly on developer tools
for most of the stuff that we care about.
So here's just a nice diagram for those of you who are interested in what overall the
implementation looks like.
There are three pieces here.
There's the ChromeDriver server and there's the browser, Chrome's multiprocess browser.
So you have that browser processing.
You have those two rendered processes.
You can see commands come will in through the HTTP server through from our WebDriver
client.
They will be delegated to a particular session.
So perhaps you might have multiple WebDriver clients talking to this one ChromeDriver server
so you might have multiple sessions and these sessions usually control their own instance
of the browser.
In this case, it might be a little bit misleading you but you can see each line has session
to the dev tool server.
Then delegates down to the particular renderers to the DevTools agent and hopefully your Web
app that you're trying to test is running in one of those renderers, and in another
one of those renderers, hopefully we have the ChromeDriver extension running to be able
to do some of the extra stuff we need to do to automate the browser on the desktop.
And then you have the extra stuff we need to do to automate the browser on the desktop.
So that's kind of some of the future stuff we're considering for this tool.
Some plans that we are wee hope to start on.
So in general, since we have switched to developer tools for the basis of controlling Chrome,
that gives us a lot more -- it's a little bit lower level than our old API.
It gives us a lot of really cool features like being able to profile what in JavaScript
on your page is taking up so much memory, what kind of memory leaks possibly do you
have.
Some interesting performance measurement stuff, access to like logs of the jobs console.
Talking more specifically about Android, we hope to -- we're considering supporting the
upcoming Chrome-backed WebView, so right now WebView is of course kind of an Android concept.
When -- when we are considering, though, supporting when Chrome -- when actually Chrome supports
or powers that WebView to be able to integrate with that and actually test that.
We are considering also running the driver on the device instead of requiring that host
configuration I was talking about earlier.
For iOS it's a little bit tricky, as I mentioned, because of the limitations in the UI WebView,
how we are using the UI WebView in Chrome for iOS.
And we're still pretty in early stages of development and kind of planning so not a
whole lot to say there, unfortunately.
So that's basically the end of what I wanted to talk about.
So if you're interested in using ChromeDriver as a tool, we have ways you can file bugs.
I have that link up there also.
There's a user forum, public user forum.
And of course since it's all open source, we love to have third-party patches, contributions,
you name it.
But that concludes my talk.
Thank you.
[ Applause ] >>Tony Voellm: Great.
Thank you, Ken.
You have come a long way since writing games based on the Power Puff Girls, so nice job.
That's what happens when they tell me these little tidbits.
Looks like we have time for one question.
If there's not a live question -- okay.
Let's go ahead and take one live question, and then we're probably going to move on to
the next talk.
Please.
>>> For some time Firefox has been able to control the -- I lost the word -- the profile.
I think that's Chrome's handling of profile now has parity with Firefox's, and I don't
think it's part of WebDriver specification.
Is that something that you're talking to Mozilla about and will continue to support, is manipulating
profiles in Chrome?
>>Ken Kania: Yeah, so to start off we are not currently talking with Mozilla about that,
but we are interested in -- maybe not supporting profiles, per 78, but there's a distinction
in Chrome, I'm not sure about the other browsers between your use data directory and also your
profile.
So for ChromeDriver we do in the tool allow you to specify a custom user directory which
maybe has several user profiles already set up, be able to do stuff like that but we don't
have any way to dynamically through the WebDriver API create new profiles or edit profiles or
anything like that.
>>Tony Voellm: Great.
Thank you, Ken.
>>Ken Kania: Thanks.
[ Applause ]