Transferred from: http://www.cnblogs.com/timsheng/archive/2012/06/12/2546957.html
By studying the source code of Selenium-webdriver, I found that the principle of webdriver is not inscrutable speculate. Here is an example of the firefox-webdriver implementation of Webdriver Ruby binding , which briefly describes how Webdriver works.
When the test script starts Firefox, Selenium-webdriver will start the Firefox browser in the new thread first. If the test script specifies Firefox profile, then start with the profile, otherwise City 1 profiles and start Firefox;
Firefox is generally started by-no-remote method, Selenium-webdriver will bind Firefox to a specific port after the completion of the binding, the Firefox instance as Webdriver remote server exists;
The client (that is, the test script) creates 1 sessions in which a restful request is sent to the remote server through an HTTP request, and the remote server resolves the request, completes the operation and returns response;
The client accepts response and parses its return value to determine whether to go to the 3rd or end script;
This is Webdriver's workflow, and it looks complicated. In fact, when we understand the principle of webdriver implementation, it should be simpler to understand the above problems.
Webdriver is designed according to the classic design pattern of server–client.
The server side is remote server, which can be any browser. When our script launches the browser, the browser is the remote server, its role is to wait for the client to send the request and make the corresponding;
The client side is simply our test code, and we test some of the behavior in the code, such as opening the browser, jumping to a specific URL, and so on, in the form of an HTTP request sent to the test browser, which is the remote Server;remote server accepting the request, and performs the corresponding operation, and returns information such as execution status, return value, etc. in response;
As a practical example, the following code is "command" Firefox to jump to the Google page:
driver = Selenium::WebDriver.for :firefoxdriver.navigate.to "http://google.com"
When executing the driver.navigate.to "http://google.com" code, the client, which is our test code, sends the following request to remote server:
Request the Localhost:port/hub/session/session_id/url address by post, request the browser to complete the jump URL operation.
If the above request is acceptable, or if remote server implements this interface, remote server jumps to the URL contained in the post data and returns the following response
{"name":"get","sessionId":"285b12e4-2b8a-4fe6-90e1-c35cba245956","status":0,"value":""}
The response contains the following information
The name of the Name:remote server-side implementation method, here is get, which represents a jump to the specified URL;
SESSIONID: The ID of the current session;
Status: The state code of the request execution, not 0 indicates not executed correctly, here is 0, means all ok don't worry;
Value: The return value of the request, where the return value is NULL, if the client calls the title interface, then the value should be the title of the current page;
If the client sends a request that locates a particular page element, the return value of response might be:
{"name":"findElement","sessionId":"285b12e4-2b8a-4fe6-90e1-c35cba245956","status":0,"value":{"ELEMENT":"{2192893e-f260-44c4-bdf6-7aad3c919739}"}}
Name,sessionid,status is similar to the above example, the difference is that the return value of the request is element:{2192893e-f260-44c4-bdf6-7aad3c919739}, which indicates the ID of the element to navigate to, through which the ID, The client can send requests such as Click to interact with the server side.
So how does the remote server side of these features be implemented? The answer is that the browser implements the unified interface of the Webdriver so that the client can automate the browser through a unified restful interface. At present, Webdriver supports IE, Chrome, Firefox, Opera and other mainstream browsers, the main reason is that these browsers implement the Webdriver conventions of the various interfaces.
[Turn] secret Webdriver implementation principle