Selenium 2. Remote Control vs Webdriver
The automation tool for functional testing of web interfaces Selenium 2 includes two products: Selenium Remote Control (Selenium 1) and Webdriver.
RC and Webdriver differ in that RC interacts with the browser using Selenium Core, a special tool that can work with any browser via JavaScript. Webdriver uses the native interface, which allows the user to more accurately repeat the actions, but to interact with each individual browser, a special driver is needed (since each browser has its own native interface), but the speed of passing the test increases. At the moment there are such drivers:
The use of the native interface also causes a minor inconvenience - any keystroke during the passage can “bring down” the test.
Both the advantage and disadvantage of Selenium RC is the use of Selenium Server Standalone. On the one hand, using the server simplifies logging the results, which greatly simplifies the writing of autotests (Webdriver has to install various crutches to find out exactly where the error occurred, because it is not always possible to determine visually due to the speed of passing the tests), but on the other hand hand - increases the time of the test and the inability to use for testing pages on a mobile device.
')
The disadvantage of the Webdriver compared to the classic RC is the difficulty of simulating actions such as hovering the mouse. On the other hand, a Webdriver, like a real user, cannot work with hidden elements or, for example, cannot enter text into a field completely blocked by another element.
Separately, it is worth mentioning about working with JavaScript and AJAX. Webdriver implements a mechanism for waiting for the completion of AJAX requests: Explicit Waits (explicit expectations) and Implicit Waits (implicit expectations) (For more, see Waits in Webdriver ). In RC, to wait for AJAX you have to use programming language tools. It is also worth noting that Remote Control does not always work correctly with JS. For example, selenium.click cannot call the JS-event onMouseDown and you have to guess, “what did the developer use there?” To write the correct command. With Webdriver, such problems do not arise.
In Selenium Remote Control, a rather wide set of commands was formed during development, while at Webdriver almost everything comes down to .click or .sendKeys (in general, a real user can do little more, however, for example, a simple command to take a screenshot or choosing Ok / Cancel in the dialog box would not hurt). However, Webdriver implemented a greater number of locators to search for an element on the page.
By.id - refers to the element by ID;
By.name - addresses by the name of the name element:
By.xpath - refers to the element by the xpath expression;
By.tagName - search by name HTML tag;
By.cssSelector - this type of locator is based on descriptions of style sheets (CSS);
By.className - search by CSS class element;
By.linkTex - search for links by text;
By.partionalLinkText - search for links on the part of the text;
Consider the examples of tests on RC and Webdriver (Java).
Let's write autotests that go to Google, enter a zerg rush into the search bar, click the search button, then after a short wait, take a screenshot of the window.
Remote Control:
Webdriver
From all the above, it is clear that both Remote Control and Webdriver have both disadvantages and advantages. In a large number of cases it is more convenient to use RC, since a large set of commands and the ability to work with hidden elements, as well as the ability to receive server logs, significantly simplify and speed up (time is money) the process of writing and subsequent adaptation of tests. Webdriver is appropriate to use where RC does not cope (does not cope well), for example for web interfaces that are overloaded with AJAX requests or in places where it is extremely important to accurately simulate user actions (it should be noted that Webdriver was implemented because -technologies Selenium RC just exhausted itself and the need for an alternative approach became apparent).
Also in Selenium 2 the possibility of transition from RC to Webdriver is implemented. Described in detail in the office. documentation.
RC and Webdriver differ in that RC interacts with the browser using Selenium Core, a special tool that can work with any browser via JavaScript. Webdriver uses the native interface, which allows the user to more accurately repeat the actions, but to interact with each individual browser, a special driver is needed (since each browser has its own native interface), but the speed of passing the test increases. At the moment there are such drivers:
- HtmlUnitDriver is a universal driver that does not require the installation of a browser;
- FirefoxDriver - driver for Firefox;
- InternetExplorerDriver - driver for IE;
- ChromeDriver - driver for Google Chrome;
- OperaDriver - driver for Opera;
- SafariDriver - Safari driver;
- AndriodDriver - driver for mobile browser on Android;
- IphoneDriver - driver for mobile browser on iPhone;
The use of the native interface also causes a minor inconvenience - any keystroke during the passage can “bring down” the test.
Both the advantage and disadvantage of Selenium RC is the use of Selenium Server Standalone. On the one hand, using the server simplifies logging the results, which greatly simplifies the writing of autotests (Webdriver has to install various crutches to find out exactly where the error occurred, because it is not always possible to determine visually due to the speed of passing the tests), but on the other hand hand - increases the time of the test and the inability to use for testing pages on a mobile device.
')
The disadvantage of the Webdriver compared to the classic RC is the difficulty of simulating actions such as hovering the mouse. On the other hand, a Webdriver, like a real user, cannot work with hidden elements or, for example, cannot enter text into a field completely blocked by another element.
Separately, it is worth mentioning about working with JavaScript and AJAX. Webdriver implements a mechanism for waiting for the completion of AJAX requests: Explicit Waits (explicit expectations) and Implicit Waits (implicit expectations) (For more, see Waits in Webdriver ). In RC, to wait for AJAX you have to use programming language tools. It is also worth noting that Remote Control does not always work correctly with JS. For example, selenium.click cannot call the JS-event onMouseDown and you have to guess, “what did the developer use there?” To write the correct command. With Webdriver, such problems do not arise.
In Selenium Remote Control, a rather wide set of commands was formed during development, while at Webdriver almost everything comes down to .click or .sendKeys (in general, a real user can do little more, however, for example, a simple command to take a screenshot or choosing Ok / Cancel in the dialog box would not hurt). However, Webdriver implemented a greater number of locators to search for an element on the page.
By.id - refers to the element by ID;
By.name - addresses by the name of the name element:
By.xpath - refers to the element by the xpath expression;
By.tagName - search by name HTML tag;
By.cssSelector - this type of locator is based on descriptions of style sheets (CSS);
By.className - search by CSS class element;
By.linkTex - search for links by text;
By.partionalLinkText - search for links on the part of the text;
Consider the examples of tests on RC and Webdriver (Java).
Let's write autotests that go to Google, enter a zerg rush into the search bar, click the search button, then after a short wait, take a screenshot of the window.
Remote Control:
import org.openqa.selenium.Keys; import com.thoughtworks.selenium.SeleneseTestCase; import java.util.concurrent.TimeUnit; import java.awt.event.KeyEvent; import java.io.BufferedWriter; import java.io.File; import java.io.FileWriter; import java.io.Writer; public class FirstTest extends SeleneseTestCase { public void setUp() throws Exception { setUp("http://google.com", "*firefox"); } public void testGoogle() throws Exception { File file = new File(" "); if (file.exists()) { file.delete(); } selenium.open("/"); // Google selenium.windowMaximize(); // selenium.waitForPageToLoad("30000"); // selenium.type("name=q", "zerg rush"); // selenium.click("name=btnG"); // TimeUnit.SECONDS.sleep(5); // 5 selenium.captureEntirePageScreenshot(" ", ""); Writer output = new BufferedWriter(new FileWriter(file)); output.write(selenium.getLog()); output.close(); System.out.println("Test Complete"); // } } Webdriver
import java.util.regex.Pattern; import java.util.concurrent.TimeUnit; import org.junit.*; import static org.junit.Assert.*; import static org.hamcrest.CoreMatchers.*; import org.openqa.selenium.*; import org.openqa.selenium.firefox.FirefoxDriver; import org.openqa.selenium.support.ui.Select; import java.awt.event.KeyEvent; import java.io.BufferedWriter; import java.io.File; import java.io.FileWriter; import java.io.Writer; import org.apache.commons.io.FileUtils; public class First_test { private WebDriver driver; private String baseUrl; private StringBuffer verificationErrors = new StringBuffer(); @Before public void setUp() throws Exception { driver = new FirefoxDriver(); baseUrl = "http://google.com"; driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS); // } @Test public void testGoogle() throws Exception { driver.get(baseUrl + "/"); // Google. baseUrl driver.findElement(By.name("q")).sendKeys("zerg rush"); // driver.findElement(By.name("btnG")).click(); // TimeUnit.SECONDS.sleep(5); // 5 File file = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); String path = " "; FileUtils.copyFile(file, new File(path)); System.out.println("Test Complete"); // } @After public void tearDown() throws Exception { driver.quit(); String verificationErrorString = verificationErrors.toString(); if (!"".equals(verificationErrorString)) { fail(verificationErrorString); } } private boolean isElementPresent(By by) { try { driver.findElement(by); return true; } catch (NoSuchElementException e) { return false } } } From all the above, it is clear that both Remote Control and Webdriver have both disadvantages and advantages. In a large number of cases it is more convenient to use RC, since a large set of commands and the ability to work with hidden elements, as well as the ability to receive server logs, significantly simplify and speed up (time is money) the process of writing and subsequent adaptation of tests. Webdriver is appropriate to use where RC does not cope (does not cope well), for example for web interfaces that are overloaded with AJAX requests or in places where it is extremely important to accurately simulate user actions (it should be noted that Webdriver was implemented because -technologies Selenium RC just exhausted itself and the need for an alternative approach became apparent).
Also in Selenium 2 the possibility of transition from RC to Webdriver is implemented. Described in detail in the office. documentation.
Source: https://habr.com/ru/post/151715/
All Articles