Advanced features

Using options

So far, we have discovered how to use different local browsers (Chrome, Firefox, Edge, Opera, Safari, PhamtomJS, HtmlUnit), Docker browsers (Chrome, Firefox, Opera), or even remote browsers with Selenium Grid. In any case, the default options are used. Nevertheless, if you have used intensively Selenium WebDriver, different questions might come to your mind:

  • What if I need to specify options (e.g. ChromeOptions, FirefoxOptions, etc) to my WebDriver object?

  • What if need to specify desired capabilities (e.g. browser type, version, platform)?

In order to support the advance features of Selenium WebDriver, Selenium-Jupiter provides several annotations aimed to allow a fine-grained control of the WebDriver object instantiation. These annotations are:

  • Options (field-level): Annotation to configure options (e.g. ChromeOptions for Chrome, FirefoxOptions for Firefox, EdgeOptions for Edge, OperaOptions for Opera, and SafariOptions for Safari).

  • Arguments (parameter-level) : Used to add arguments to the options.

  • Preferences (parameter-level) : Used to set preferences to the options.

  • Binary (parameter-level) : Used to set the location of the browser binary.

  • Extensions (parameter-level) : User to add extensions to the browser.

The annotations marked as parameter-level are applied to a single WebDriver parameter. The annotations marked as field-level are applied globally in a test class.

The following example shows how to specify options for Chrome. In the first test (called headlessTest), we are setting the argument --headless, used in Chrome to work as a headless browser. In the second test (webrtcTest), we are using two different arguments: --use-fake-device-for-media-stream and --use-fake-ui-for-media-stream, used to fake user media (i.e. camera and microphone) in WebRTC applications. In the third test (extensionTest), we are adding an extension to Chrome using the @Extensions annotation. The value of this field is an extension file that will be searched: i) using value as its relative/absolute path; ii) using value as a file name in the project classpath.

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.openqa.selenium.By;
import org.openqa.selenium.chrome.ChromeDriver;

import io.github.bonigarcia.seljup.Arguments;
import io.github.bonigarcia.seljup.Extensions;
import io.github.bonigarcia.seljup.SeleniumExtension;

@ExtendWith(SeleniumExtension.class)
public class ChromeWithOptionsJupiterTest {

    @Test
    void headlessTest(@Arguments("--headless") ChromeDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

    @Test
    void webrtcTest(@Arguments({ "--use-fake-device-for-media-stream",
            "--use-fake-ui-for-media-stream" }) ChromeDriver driver) {
        driver.get(
                "https://webrtc.github.io/samples/src/content/devices/input-output/");
        assertThat(driver.findElement(By.id("video")).getTagName(),
                equalTo("video"));
    }

    @Test
    void extensionTest(@Extensions("hello_world.crx") ChromeDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

As introduced before, this annotation @Options can be used also at field-level, as shown in this other example. This test is setting to true the Firefox preferences media.navigator.streams.fake and media.navigator.permission.disabled, used also for WebRTC.

import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.openqa.selenium.By;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxOptions;

import io.github.bonigarcia.seljup.Options;
import io.github.bonigarcia.seljup.SeleniumExtension;

@ExtendWith(SeleniumExtension.class)
public class FirefoxWithGlobalOptionsJupiterTest {

    @Options
    FirefoxOptions firefoxOptions = new FirefoxOptions();
    {
        // Flag to use fake media for WebRTC user media
        firefoxOptions.addPreference("media.navigator.streams.fake", true);

        // Flag to avoid granting access to user media
        firefoxOptions.addPreference("media.navigator.permission.disabled",
                true);
    }

    @Test
    public void webrtcTest(FirefoxDriver driver) {
        driver.get(
                "https://webrtc.github.io/samples/src/content/devices/input-output/");
        assertThat(driver.findElement(By.id("video")).getTagName(),
                equalTo("video"));
    }

}

Template tests

Selenium-Jupiter takes advantage on the standard feature of JUnit 5 called test templates. Test templates can be seen as an special kind of parameterized tests, in which the test is executed several times according to the data provided by some extension. In our case, the extension is Selenium-Jupiter itself, and the test template is configured using a custom file in JSON called browsers scenario.

Let’s see some examples. Consider the following test. A couple of things are new in this test. First of all, instead of declaring the method with the usual @Test annotation, we are using the JUnit 5’s annotation @TestTemplate. With this we are saying to JUnit that this method is not a regular test case but a template. Second, the parameter type of the method templateTest is WebDriver. This is the generic interface of Selenium WebDriver, and the concise type (i.e. ChromeDriver, FirefoxDriver, RemoteWebDriver, etc.) will be determined by Selenium-Jupiter in runtime.

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.TestTemplate;
import org.junit.jupiter.api.extension.RegisterExtension;
import org.openqa.selenium.WebDriver;

import io.github.bonigarcia.seljup.SeleniumExtension;

public class TemplateTest {

    @RegisterExtension
    static SeleniumExtension seleniumExtension = new SeleniumExtension();

    @TestTemplate
    void templateTest(WebDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

The last piece we need in this test template is what we call browser scenario. As introduced before, this scenario is defined in a JSOn file following a simple notation.

The path of the JSON browser scenario is established in the configuration key called sel.jup.browser.template.json.file. By default, this key has the value classpath:browsers.json. This means that the JSON scenario is defined in a file called browsers.json located in the classpath (see section Configuration for further details about configuration).

If the configuration key sel.jup.browser.template.json.file do not start with the word classpath:, the file will be searched using relative of absolute paths.

Now imagine that the content of the file browsers.json is as follows:

{
   "browsers": [
      [
         {
            "type": "chrome-in-docker",
            "version": "latest"
         }
      ],
      [
         {
            "type": "chrome-in-docker",
            "version": "latest-1"
         }
      ],
      [
         {
            "type": "chrome-in-docker",
            "version": "beta"
         }
      ],
      [
         {
            "type": "chrome-in-docker",
            "version": "unstable"
         }
      ]
   ]
}

When we execute the template test, in this case we will have four actual tests: the first using the latest version of Chrome, the second using the previous to stable version of Chrome (latest-1), the third using the beta version of Chrome (beta), and another test using the development version of Chrome (unstable). For instance, if we run the test in Eclipse, we will get the following output:

test template 01
Figure 1. Example of test template execution in Eclipse

Generally speaking, a browser within the JSON scenario is defined using the following parameters:

  • type: Type of browsers. The accepted values are:

    • chrome: For local Chrome browsers.

    • firefox: For local Firefox browsers.

    • edge: For local Edge browsers.

    • iexplorer: For local Internet Explorer browsers.

    • opera: For local Opera browsers.

    • safari: For local Safari browsers.

    • appium: For local mobile emulated devices.

    • phantomjs: For local PhtanomJS headless browsers.

    • chrome-in-docker: For Chrome browsers in Docker.

    • firefox-in-docker: For Firefox browsers in Docker.

    • opera-in-docker: For Opera browsers in Docker.

    • android: For web browsers in Android devices in Docker containers.

  • version: Optional value for the version. Wildcard for latest versions (latest, latest-1, etc) are accepted. Concrete versions are also valid (e.g. 63.0, 58.0, etc., depending of the browser). Beta and unstable (i.e. development) versions for Chrome and Firefox are also supported (using the labels beta and unstable labels respectively).

  • deviceName: Also for android type, the device type can be specified (Samsung Galaxy S6, Nexus 4, Nexus 5, etc.).

Finally, more than one parameters can be defined in the test template. For instance, consider the following test in which a couple of WebDriver parameters are declared in the test template.

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.TestTemplate;
import org.junit.jupiter.api.extension.RegisterExtension;
import org.openqa.selenium.WebDriver;

import io.github.bonigarcia.seljup.SeleniumExtension;

public class TemplateTwoBrowsersTest {

    @RegisterExtension
    static SeleniumExtension seleniumExtension = new SeleniumExtension();

    @TestTemplate
    void templateTest(WebDriver driver1, WebDriver driver2) {
        driver1.get("https://bonigarcia.github.io/selenium-jupiter/");
        driver2.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver1.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
        assertThat(driver2.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

The JSON scenario should be defined accordingly. Each browser array in this case (for each test template execution) should declare two browsers. For instance, using the following JSON scenario, the first execution will be based on Chrome in Docker (first parameter) and Firefox in Docker (second parameter); and the second execution will be based on a local Chrome (first parameter) and the headless browser PhantomJS (second parameter).

{
   "browsers": [
      [
         {
            "type": "chrome-in-docker"
         },
         {
            "type": "firefox-in-docker"
         }
      ],
      [
         {
            "type": "chrome"
         },
         {
            "type": "phantomjs"
         }
      ]
   ]
}

If we execute this test using in GUI, the JUnit tab shows two tests executed with the values defined in the JSON scenario.

test template 02
Figure 2. Example of test template execution (with two parameters) in Eclipse

As of version 2.2.0, Selenium-Jupiter allows to configure the browser scenario programmatically using the JUnit 5 @RegisterExtension annotation. To that aim, the method addBrowsers of the SeleniumExtension instance is used to add different browser(s) to the scenario. In the following example the test is executed twice, one using Chrome and the second using Firefox.

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.TestTemplate;
import org.junit.jupiter.api.extension.RegisterExtension;
import org.openqa.selenium.WebDriver;

import io.github.bonigarcia.seljup.BrowserBuilder;
import io.github.bonigarcia.seljup.BrowsersTemplate.Browser;
import io.github.bonigarcia.seljup.SeleniumExtension;

public class TemplateRegisterTest {

    @RegisterExtension
    static SeleniumExtension seleniumExtension = new SeleniumExtension();

    @BeforeAll
    static void setup() {
        Browser chrome = BrowserBuilder.chrome().build();
        Browser firefox = BrowserBuilder.firefox().build();
        seleniumExtension.addBrowsers(chrome);
        seleniumExtension.addBrowsers(firefox);
    }

    @TestTemplate
    void templateTest(WebDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

Generic driver

As of version 2.1.0, Selenium-Jupiter allows to use a configurable WebDriver object. This generic driver is declared as usual (i.e. as test method or constructor parameter) using the type RemoteWebDriver or WebDriver. The concrete type of browser to be used is established using the configuration key sel.jup.default.browser. The default value for this key is chrome-in-docker. All the values used in the template test defined in the previous section (i.e. chrome, firefox, edge, chrome-in-docker, firefox-in-docker, android, etc.) can be used also to define the type of browser in this mode.

For instance, the following test, if no additional configuration is done, will use Chrome in Docker as browser:

import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.openqa.selenium.WebDriver;

import io.github.bonigarcia.seljup.SeleniumExtension;

@ExtendWith(SeleniumExtension.class)
public class GenericTest {

    @Test
    void genericTest(WebDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

If the resolution of this browser finishes with exception (for instance, when executing the test in a host without Docker), a list of browser fallback will be used. This list is managed using the configuration key sel.jup.default.browser.fallback. By default, this key has the value chrome,firefox,safari,edge,phantomjs, meaning that the first fallback browser is a local Chrome, then local Firefox, then local Safari, then local Edge, and finally PhantomJS (headless browser).

The version of the generic browser (in case of Docker browsers) is managed with the key sel.jup.default.version (latest by default). The versions of the fallback browsers can be also managed, this time using the configuration key sel.jup.default.browser.fallback.version.

Integration with Jenkins

Selenium-Jupiter provides seamless integration with Jenkins through one of its plugins: the Jenkins attachment plugin. The idea is to provide the ability to attache output files (typically PNG screenshots and MP4 recordings of Docker browsers), and keep these files attached to the job execution. This is done in Selenium-Jupiter setting the configuration key sel.jup.output.folder to an special value: surefire-reports.

When this configuration key is configured with that value, Selenium-Jupiter will store the generated files in the proper folder, in a way that the Jenkins attachment plugin is able to find those files and export them in the Jenkins GUI. For instance, consider the following test, when is executed in Jenkins (with the attachment plugin) and the following configuration:

mvn clean test -Dtest=DockerFirefoxWithOptionsJupiterTest -Dsel.jup.recording=true -Dsel.jup.output.folder=surefire-reports -Dsel.jup.screenshot.at.the.end.of.tests=true

In this case, at the the execution of this test, two recordings in MP4 and two screenshots in PNG will be attached to the job as follows.

jenkins attachements test
Figure 3. Example of test execution through Jenkins with attachments

We can watch the recording simply clicking in the attached MP4 files.

jenkins attachements test mp4
Figure 4. Example of test execution through Jenkins with attachments

Test template are also compatible with this feature. For instance, consider the following test test. When is executed in Jenkins using the configuration below, the following attachments will be available on Jenkins:

mvn clean test -Dtest=TemplateTest -Dsel.jup.recording=true -Dsel.jup.output.folder=surefire-reports -Dsel.jup.screenshot.at.the.end.of.tests=true
jenkins attachements template
Figure 5. Example of template test execution through Jenkins with attachments

And we will be able to watch the recording:

jenkins attachements template mp4
Figure 6. Example of template test execution through Jenkins with attachments

Using Genymotion

The use of Genymotion for using Android devices in the cloud is possible as of Selenium-Jupiter 3.1.0. This feature is used using a Software as a Service (SaaS) approach. In order to use this feature, we need to select GENYMOTION_SAAS in the cloud parameter of @DockerBrowser in a test. First, we need a valid Genymotion account. This account will be configured using the methods setAndroidGenymotionUser(), setAndroidGenymotionPassword() and setAndroidGenymotionLicense() for user, password, and license respectively. Moreover, we need to specify the following values:

  • Genymotion template name (method setAndroidGenymotionTemplate()).

  • Android version (method setAndroidGenymotionAndroidVersion()).

  • Android API level (method setAndroidGenymotionAndroidApi()).

  • Android screen size (method setAndroidGenymotionScreenSize()).

All this values will be internally managed using a label specified with setAndroidGenymotionDeviceName(). This label will be used later in the actual test in the deviceName value. The following test shows an example:

import static io.github.bonigarcia.seljup.BrowserType.ANDROID;
import static io.github.bonigarcia.seljup.CloudType.GENYMOTION_SAAS;
import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;

import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.RegisterExtension;
import org.openqa.selenium.remote.RemoteWebDriver;

import io.github.bonigarcia.seljup.DockerBrowser;
import io.github.bonigarcia.seljup.SeleniumExtension;
import io.github.bonigarcia.seljup.config.Config;

public class AndroidGenymotionJupiterTest {

    @RegisterExtension
    static SeleniumExtension seleniumExtension = new SeleniumExtension();

    @BeforeAll
    static void setup() {
        Config config = seleniumExtension.getConfig();
        config.setAndroidGenymotionDeviceName("SamsungS7V6");
        config.setAndroidGenymotionTemplate("Samsung Galaxy S7");
        config.setAndroidGenymotionAndroidVersion("6.0.0");
        config.setAndroidGenymotionAndroidApi("23");
        config.setAndroidGenymotionScreenSize("1440x2560");

        // The following values need to be set (it can be overridden using Java
        // properties or environment variables)
        config.setAndroidGenymotionUser("my-genymotion-user");
        config.setAndroidGenymotionPassword("my-genymotion-pass");
        config.setAndroidGenymotionLicense("my-genymotion-license");
    }

    @Test
    public void testAndroidInGenymotionSaas(
            @DockerBrowser(type = ANDROID, cloud = GENYMOTION_SAAS, deviceName = "SamsungS7V6", browserName = "browser")
            RemoteWebDriver driver) {
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

}

We can see the execution of the test in the Genymotion dashboard while the test is being executed. For the example before, we see the following Android device:

genymotion
Figure 7. Example of test execution in Genymotion

Notice that Selenium_Jupiter downloads the chromedriver binary required by internal Appium server contained in the internal Docker container which is used to connect with Genymotion SaaS. By default, the version of the chromedriver binary is related with the installed browser. The following table shows a summary of the chromedriver versions managed by Selenium_Jupiter depending on the Android API level. It other version of chromedriver is required, it can specified using the method setAndroidGenymotionChromedriver().

Table 1. Versions of chromedriver handled by Selenium-Jupiter for Genymotion
Android API level chromedriver version

21

2.21

22

2.13

23

2.18

24

2.23

25

2.28

26

2.31

27

2.33

28

2.40

Single session

By default, the instances provided by Selenium_Jupiter (e.g. ChromeDriver, FirefoxDriver, etc) are created before each test, and are disposed after each test. As of Selenium_Jupiter 3.2.0, this default behavior can be changed using the class-level annotation @SingleSession. The instances provided in this case will be created before all tests, and are disposed after all tests.

The following test shows an example of this feature. As you can seen, this test uses the ordering capability provided as of JUnit 5.4. The browser (Chrome in this case) is available at the beginning for the tests. According to the given order, first testStep1() is executed. Then, the session (i.e. the same browser in the same state) is used by the second test, testStep2(). An the end of all tests, the browser is closed.

import static java.lang.invoke.MethodHandles.lookup;
import static org.hamcrest.CoreMatchers.containsString;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.slf4j.LoggerFactory.getLogger;

import org.junit.jupiter.api.MethodOrderer.OrderAnnotation;
import org.junit.jupiter.api.Order;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.TestMethodOrder;
import org.junit.jupiter.api.extension.ExtendWith;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.slf4j.Logger;

import io.github.bonigarcia.seljup.SeleniumExtension;
import io.github.bonigarcia.seljup.SingleSession;

@ExtendWith(SeleniumExtension.class)
@TestMethodOrder(OrderAnnotation.class)
@SingleSession
public class OrderedJupiterTest {

    final Logger log = getLogger(lookup().lookupClass());

    RemoteWebDriver driver;

    public OrderedJupiterTest(ChromeDriver driver) {
        this.driver = driver;
    }

    @Test
    @Order(1)
    public void testStep1() {
        log.debug("Step 1: {}", driver);
        driver.get("https://bonigarcia.github.io/selenium-jupiter/");
        assertThat(driver.getTitle(),
                containsString("JUnit 5 extension for Selenium"));
    }

    @Test
    @Order(2)
    public void testStep2() {
        log.debug("Step 2: {}", driver);
        WebElement about = driver.findElementByLinkText("About");
        assertTrue(about.isDisplayed());
        about.click();
    }

}

Selenium-Jupiter CLI

As of version 2.1.0, Selenium-Jupiter can used interactively from the shell as a regular command line interface (CLI) tool. In this mode, Selenium-Jupiter allows to get the VNC session of Docker browser. There are two ways of using this feature:

  • Directly from the source code, using Maven. The command to be used is mvn exec:java -Dexec.args="browserName <version>". For instance:

$ mvn exec:java -Dexec.args="chrome beta"
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building selenium-jupiter 3.2.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ selenium-jupiter ---
[INFO] Using SeleniumJupiter to execute chrome beta in Docker
[INFO] Using CHROME version beta
[INFO] Starting Docker container aerokube/selenoid:1.8.4
[DEBUG] Creating WebDriver for CHROME at http://172.17.0.1:32911/wd/hub
Jan 24, 2019 1:09:04 AM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: OSS
[INFO] Starting Docker container psharkey/novnc:3.3-t6
[INFO] Session id ee7200775c466c8526c77e7eb2495557
[INFO] VNC URL (copy and paste in a browser navigation bar to interact with remote session)
[INFO] http://172.17.0.1:32912/vnc.html?host=172.17.0.1&port=32911&path=vnc/ee7200775c466c8526c77e7eb2495557&resize=scale&autoconnect=true&password=selenoid
[INFO] Press ENTER to exit

[INFO] Stopping Docker container aerokube/selenoid:1.8.4
[INFO] Stopping Docker container psharkey/novnc:3.3-t6
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:10 min
[INFO] Finished at: 2018-03-31T17:51:15+02:00
[INFO] Final Memory: 27M/390M
[INFO] ------------------------------------------------------------------------
  • Using Selenium-Jupiter as a fat-jar. This jar can be created using the command mvn compile assembly:single from the source code, and then java -jar selenium-jupiter.jar browserName <version>. For instance:

$ java -jar selenium-jupiter-3.2.0-fat.jar firefox
[INFO] Using SeleniumJupiter to execute firefox (latest) in Docker
[INFO] Using FIREFOX version 66.0 (latest)
[INFO] Pulling Docker image aerokube/selenoid:1.8.4
[INFO] Starting Docker container aerokube/selenoid:1.8.4
[DEBUG] Creating WebDriver for FIREFOX at http://172.17.0.1:32909/wd/hub
Jan 24, 2019 1:08:15 AM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: W3C
[INFO] Starting Docker container psharkey/novnc:3.3-t6
[INFO] Session id 2356ceb4-53f6-49d5-bae0-3072faa47ad2
[INFO] VNC URL (copy and paste in a browser navigation bar to interact with remote session)
[INFO] http://172.17.0.1:32910/vnc.html?host=172.17.0.1&port=32909&path=vnc/2356ceb4-53f6-49d5-bae0-3072faa47ad2&resize=scale&autoconnect=true&password=selenoid
[INFO] Press ENTER to exit

[INFO] Stopping Docker container aerokube/selenoid:1.8.4
[INFO] Stopping Docker container psharkey/novnc:3.3-t6
As of version 2.2.0, the parameter browserName can be used to select an android device. In this case, an addition parameter can be specified: deviceName for the device type (Samsung Galaxy S6, Nexus 4, Nexus 5, etc.).

Selenium-Jupiter Server

As of version 3.0.0, Selenium-Jupiter can used as a server. To start this mode, the shell is used. Once again, two options are allowed:

  • Directly from the source code and Maven. The command to be used is mvn exec:java -Dexec.args="server <port>". If the second argument is not specified, the default port will be used (4042):

$ mvn exec:java -Dexec.args="server"
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Selenium-Jupiter 3.2.0
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- exec-maven-plugin:1.6.0:java (default-cli) @ selenium-jupiter ---
[INFO] Selenium-Jupiter server listening on http://localhost:4042/wd/hub
  • Using Selenium-Jupiter as a fat-jar. For instance:

> java -jar webdrivermanager-3.2.0-fat.jar server
[INFO] Selenium-Jupiter server listening on http://localhost:4042/wd/hub

When the Selenium-Jupiter server is up and running, it acts as a regular Selenium Server for Docker browsers (Chrome, Firefox,. Opera, Android), and its URL can be used in tests using regular Selenium’s RemoteWebDriver objects.