Test java in chrome

Selenium Chrome WebDriver Test Cases with JUnit in Java

In this example we will show you how to run Selenium Chrome WebDriver Test Cases with JUnit in Java. In order to run Selenium Chrome Test Cases you need the ChromeDriver which you can download here. You need to set the location as a system property namely: webdriver.chrome.driver . You can add this property as a system property or you can pass the value as an argument to maven which I explained below.

Maven Dependencies

You need to add the following dependencies to your project.

 junit junit 4.11  org.seleniumhq.selenium selenium-java 2.44.0 

Selenium Chrome WebDriver with JUnit

You need to create a ChromeDriver implementation of the WebDriver . You can do this by creating a new ChromeDriver() . This ChromeDriver needs to know where the executable file is located. You can tell this by setting the webdriver.chrome.driver either by a System Property or you can pass this as a Maven Argument. After you initialized the ChromeDriver you can do the actual testing. For simplicity we just acquire a web resource. After the test is completed we need to clean up the WebDriver.

package com.memorynotfound.test; import org.junit.AfterClass; import org.junit.BeforeClass; import org.junit.Test; import org.openqa.selenium.WebDriver; import org.openqa.selenium.chrome.ChromeDriver; public class ChromeSeleniumTest < private static WebDriver driver; @BeforeClass public static void setUp()< System.setProperty("webdriver.chrome.driver", "/selenium-driver/chromedriver"); driver = new ChromeDriver(); >@Test public void testChromeSelenium() < driver.get("https://memorynotfound.com/"); >@AfterClass public static void cleanUp() < if (driver != null) < driver.close(); driver.quit(); >> >

Executing Selenium Chrome WebDriver Test Cases with Maven

When you execute the Selenium Chrome WebDriver Test Cases you can see that chrome start up a new instance and that the page is reached.

Info: If you don’t want to hard code the location of the chrome driver, you can also pass the location of chrome driver as an argument to Maven.

mvn clean test -Dwebdriver.chrome.driver=/selenium-driver/chromedriver

Output

[INFO] Scanning for projects. [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building SELENIUM - chrome-example 1.0.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [. ] ------------------------------------------------------- T E S T S ------------------------------------------------------- Running com.memorynotfound.test.ChromeSeleniumTest Starting Selenium Chrome WebDriver 2.14.313457 (3d645c400edf2e2c500566c9aa096063e707c9cf) on port 36247 Only local connections are allowed. Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.492 sec Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS (Selenium Chrome WebDriver) [INFO] ------------------------------------------------------------------------ [INFO] Total time: 7.483 s [INFO] Finished at: 2015-02-06T19:22:13+01:00 [INFO] Final Memory: 15M/245M [INFO] ------------------------------------------------------------------------

References

Источник

Testing

There are several test suites for verifying ChromeDriver’s correctness:

Test Suite	Purpose	Frequency
Unit tests	Quick tests for verifying individual objects or functions	CQ
Python integration tests	Verify important features work correctly with Chrome	CQ
Java acceptance tests	Verify correct interaction with Chrome and Selenium Java API	Manual runs
Web platform tests	Verify W3C standard complaince	CI waterfall
JavaScript unit tests	Verify ChromeDriver’s JavaScript functions	CQ

Unit tests ( chromedriver_unittests )

Many C++ source files for ChromeDriver have corresponding unit test files, with filenames ending in _unittest.cc . These tests should be very quick (each taking no more than a few milliseconds) and be very stable. We run them on the commit queue on all desktop platforms.

Here are the commands to build and run the unit tests:

autoninja -C out/Default chromedriver_unittests out/Default/chromedriver_unittests 

Python integration tests

These tests are maintained by the ChromeDriver team, and are intended to verify that ChromeDriver works correctly with Chrome. They are written in Python script, in test/run_py_tests.py . We run these tests on the CQ (commit queue) on all desktop platforms, and plan to run them on Android as well in the future.

In the examples below CHROMEDRIVER_DIR is chrome/test/chromedriver if you are in a chromium checkout.

To run these tests, first build Chrome and ChromeDriver, and then invoke run_py_tests.py :

autoninja -C out/Default chrome chromedriver vpython3 CHROMEDRIVER_DIR>/test/run_py_tests.py --chromedriver=out/Default/chromedriver 

The run_py_tests.py script has a number of options. Run it with —help for more information. The only require option is —chromedriver to specify the location of the ChromeDriver binary.

Test filtering

The —filter option can be used on run_py_tests.py command line to filter the tests to run. Inside the filter, tests must be specified using the format moduleName.className.testMethodName , where moduleName is always __main__ , className is the name of the Python class containing the test, and testMethodName is the Python method defining the test. For example —filter=__main__.ChromeDriverTest.testLoadUrl .

The * character can be used inside the filter as a wildcard.

To specify multiple tests in the filter, separate them with : characters.

Disabling an integration test

If there are any test cases that fail or are flaky, and you can’t fix them quickly, please add the test names to one of the filters near the beginning of run_py_tests.py . If the failure is due to a bug, please file an issue at https://crbug.com/chromedriver/new and include the link to the issue as a comment. If the failure is intentional (e.g., a feature is not supported on a particilar platform), explain it in a comment.

Running in Commit Queue

The Python integration tests are run in the Commit Queue (CQ) in a step named chromedriver_py_tests .

When running inside the CQ, the —test-type=integration option is passed to the run_py_tests.py command line. This has the following effects:

• All tests listed in _INTEGRATION_NEGATIVE_FILTER are skipped. Tests in this list should have comments indicating why they should be skipped in the CQ.
• If there are a small number of test failures (no more than 10), then all failed tests are retried at the end. This is to prevent flaky tests from causing CQ failures.

Testing on Android

The Python integration tests can be used to verify ChromeDriver interaction with Chrome running on Android devices. This requires the following equipment:

• A Linux machine to run the Python script and ChromeDriver. (While ChromeDriver can also control Android Chrome from Windows and Mac, the Python integration tests only support controlling Android Chrome from Linux.)
• An Android device attached to the Linux machine. This device must have USB debugging enabled.

To run the tests, invoke run_py_tests.py with —android-package=package_name option, where package_name can be one of the following values:

• chrome_stable : normal in-box Chrome that is installed by the system.
• chrome_beta : Beta build of Chrome.
• chromium : Open source Chromium build.

WebDriver Java acceptance tests ( test/run_java_tests.py )

These are integration tests from the Selenium WebDriver open source project. They are not currently run on any bots, but we have plan to include these tests in the commit queue in the future.

The source code for these tests are in the Selenium repository at https://github.com/SeleniumHQ/selenium/tree/master/java/client/test/org/openqa/selenium. We compile these tests, and store them in a special repository at https://chromium.googlesource.com/chromium/deps/webdriver/. We use a Python script test/run_java_tests.py to drive these tests.

Before running these tests, you need to do a one-time setup with the following commands:

mkdir CHROMEDRIVER_DIR>/third_party cd CHROMEDRIVER_DIR>/third_party git clone https://chromium.googlesource.com/chromium/deps/webdriver java_tests 

After the setup, the tests can be run with

python3 CHROMEDRIVER_DIR>/test/run_java_tests.py --chromedriver=out/Default/chromedriver 

The run_py_tests.py script has a number of options. Run it with —help for more information. The only require option is —chromedriver to specify the location of the ChromeDriver binary.

Disabling a Java acceptance test

If there are any test cases that fail or are flaky, and you can’t fix them quickly, please add the test names to one of the filters in test_expectations file in the same directory as run_java_tests.py .

Web Platform Tests (WPT)

The Web Platform Tests (WPT) project is a W3C-coordinated attempt to build a cross-browser testsuit to verify how well browsers conform to web platform standards. Here, we will only focus on the WebDriver portion of WPT. You can either use the tests bundled with Chromium source code or the tests checked out externally from the WPT official repo.

External WPT checkout

To run WPT WebDriver tests, first clone the tests from GitHub into an empty directory:

git clone https://github.com/web-platform-tests/wpt 

If necessary, install Python virtualenv module on your system. This only needs to be done once. The command for the installation depends on your system, but is usually something like:

Now you can change into the WPT repository location, and run WPT WebDriver tests with the following command:

./wpt run [options] chrome webdriver 

Use ./wpt run —help to see all available options. The following are the most useful options:

• —webdriver-binary /path/to/chromedriver specifies the ChromeDriver binary to use. Without this option, the test runner will try to find ChromeDriver on your PATH, or download ChromeDriver if it is not already on the PATH.
• —binary /path/to/chrome specifies the Chrome binary to use.
• —webdriver-arg=. specifies additional arguments to be passed to the ChromeDriver command line. For example, to create a ChromeDriver verbose log, use —webdriver-arg=—verbose —webdriver-arg=—log-path=/path/to/log —webdriver-arg=—append-log . Note the following:
  • Each ChromeDriver switch needs a separate —webdriver-arg . Don’t concatenate multiple switches together.
  • Each ChromeDriver switch must be connected with —webdriver-arg with an = sign.
  • —webdriver-arg=—append-log is recommended. Sometimes the test runner needs to restart ChromeDriver during tests, and this can cause ChromeDriver to overwrite logs without this switch.

  The WPT WebDriver tests are organized into subdirectories, one for each WebDriver command defined in the W3C spec. You can select a subset of the tests with the last argument on the WPT command line. For example, to run all tests for the New Session command, use

  ./wpt run [options] chrome webdriver/tests/new_session 

  Bundled WPT

  The tests are located in //third_party/blink/web_tests/external/wpt directory. You can use the following command to run them.

  testing/xvfb.py chrome/test/chromedriver/test/run_webdriver_tests.py \ --chromedriver=out/Release/chromedriver \ --test-path=third_party/blink/web_tests/external/wpt/test-offset> 

  Note: The path to the tests must be specified relatively to the Chromium source code root.

  JavaScript Unit Tests

  All ChromeDriver JavaScript files in the js directory have corresponding unit tests, stored in HTML files. These tests can be run in two ways:

  • They are run as part of the Python integration tests ( run_py_tests.py ) menteioned above, through a test class named JavaScriptTests . As a result of this, these tests are run in the CQ (commit queue).
  • They can be run manually, by using Chrome to load the HTML file containing the tests. After the HTML file is loaded, open DevTools pane and switch to the Console tab to see the test results.

  Источник