This file contains high-level info about how ChromeDriver works and how to contribute. ChromeDriver is an implementation of the WebDriver standard, which allows users to automate testing of their website across browsers. See the user site at https://sites.google.com/a/chromium.org/chromedriver/ =====Getting started===== Build ChromeDriver by building the 'chromedriver' target. This will create an executable binary in the build folder named 'chromedriver[.exe]'. Once built, ChromeDriver can be used interactively with python. $ export PYTHONPATH=<THIS_DIR>/server:<THIS_DIR>/client $ python >>> import server >>> import chromedriver >>> cd_server = server.Server('/path/to/chromedriver/executable') >>> driver = chromedriver.ChromeDriver(cd_server.GetUrl()) >>> driver.Load('http://www.google.com') >>> driver.Quit() >>> cd_server.Kill() ChromeDriver will use the system installed Chrome by default. To use ChromeDriver2 with Chrome on Android pass the Android package name in the chromeOptions.androidPackage capability when creating the driver. The path to adb_commands.py and the adb tool from the Android SDK must be set in PATH. For more detailed instructions see the user site. =====Architecture===== ChromeDriver is shipped separately from Chrome. It controls Chrome out of process through DevTools. ChromeDriver is a standalone server which communicates with the WebDriver client via the WebDriver wire protocol, which is essentially synchronous JSON commands over HTTP. WebDriver clients are available in many languages, and many are available from the open source selenium/webdriver project: http://code.google.com/p/selenium. ChromeDriver uses the webserver from net/server. ChromeDriver has a main thread, called the command thread, an IO thread, and a thread per session. The webserver receives a request on the IO thread, which is sent to a handler on the command thread. The handler executes the appropriate command function, which completes asynchronously. The create session command may create a new thread for subsequent session-related commands, which will execute on the dedicated session thread synchronously. When a command is finished, it will invoke a callback, which will eventually make its way back to the IO thread as a HTTP response for the server to send. =====Code structure (relative to this file)===== 1) . Implements chromedriver commands. 2) chrome/ A basic interface for controlling Chrome. Should not depend on or reference WebDriver-related code or concepts. 3) js/ Javascript helper scripts. 4) net/ Code to deal with network communication, such as connection to DevTools. 5) client/ Code for a python client. 6) server/ Code for the chromedriver server. A python wrapper to the chromedriver server. 7) extension/ An extension used for automating the desktop browser. 8) test/ Integration tests. 9) third_party/ Third party libraries used by chromedriver. =====Testing===== See the ChromeDriver waterfall at: http://build.chromium.org/p/chromium.chromedriver/waterfall There are 4 test suites for verifying ChromeDriver's correctness: 1) chromedriver_unittests (chrome/chrome_tests.gypi) This is the unittest target, which runs on the main waterfall on win/mac/linux and can close the tree. It is also run on the commit queue and try bots by default. Tests should take a few milliseconds and be very stable. 2) chromedriver_tests (chrome/chrome_tests.gypi) This is a collection of C++ medium sized tests which can be run optionally on the trybots. 3) python integration tests Run test/run_py_tests.py --help for more info. These are only run on the ChromeDriver waterfall. 4) WebDriver Java acceptance tests These are integration tests from the WebDriver open source project which can be run via test/run_java_tests.py. They are only run on the ChromeDriver bots. Run with --help for more info. =====Contributing===== Find an open issue and submit a patch for review by an individual listed in the OWNERS file in this directory. Issues are tracked in chromedriver's issue tracker: https://code.google.com/p/chromedriver/issues/list