How to use setName method of org.openqa.selenium.remote.tracing.empty.NullSpan class

You are absolutely right that incidental and often changing details in the produced scripts is the biggest problem of record-and-playback automation. You can obviously remove the details from the scripts after recording, but in my opinion it's better to build reusable libraries and code scripts manually from the start.

A good alternative for coding scripts using "real" programming languages is using some higher level automation framework such as Robot Framework that you mentioned. As you speculated, Robot's reusable keywords and also variables make extracting details away from tests very easy. The test cases in SeleniumLibrary's demo illustrates this very well and the demo also shows how to use Selenium through Robot.

You also asked about Sikuli. I've never used it myself but it sure looks interesting. You might be interested on this great how-to that explains how to use it through Robot Framework.

Short answer: If you're not already using Selenium Remote Control (RC), you want to use the WebDriver option.

Longer answer: RC is the older 1.0 version of Selenium. WebDriver is the newer 2.0 version. WebDriver-Backed is a middle ground, allowing you to use the old RC API through the new WebDriver implementation.

You can switch between the options in the IDE and see for yourself the different tests that are generated.

More info in the Selenium docs

With GeckoDriver v0.20.0 and Firefox Quantum v59.0.2 (64-bits) your code block looks good and the log stack trace looks equally good enough sans the log message :

Promise rejected while context is inactive: Message manager disconnected

As per the discussion in Mozilla Support Forum this error seems to be Privacy Badger. In short this issue is caused by an extension that isn't loaded/working properly.

Solution

• Upgrade JDK to recent levels JDK 8u162.
• Upgrade Selenium to current levels Version 3.11.0.
• Clean your Project Workspace through your IDE and Rebuild your project with required dependencies only.
• Use CCleaner tool to wipe off all the OS chores before and after the execution of your Test Suite.
• If your base Firefox version is too old, then uninstall it through Revo Uninstaller and install a recent GA and released version of Firefox.
• Take a System Reboot.
• Execute your @Test.

tl;dr

Are unresolved promises rejected prior to a window.unload event?

---

Update

Well, as I mentioned in my Answer your stack trace was fair enough as per current implementations. But personally I haven't seen this trace on my localhost :

Promise rejected while context is inactive: Message manager disconnected

Of-coarse some traces can be dependent of the underlying OS. Now going through the entire discussion Are unresolved promises rejected prior to a window.unload event? the bottom-line seems :

The problem of promises from unloading pages (or indeed script invocation in unloaded pages in general) not being specified very well and not being interoperably implemented is very real. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1058695 where we ended up putting in some mitigations in Gecko that technically don't follow the spec, because technically following the spec requires leaking the world in common cases.... The problem is that there is no spec for this event loop stuff right now, and the spec for Promise is part of ES6, which doesn't really doesn't admit the possibility of Realms needing to go away in some sense, so there's nothing to even raise such issues against.

Hence the conclusion is You are good to race ahead

Best practice, according to most sites I've seen, is to keep the asserts out of the page objects. One example is below from the Selenium docs.

http://www.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern

There is a lot of flexibility in how the page objects may be designed, but there are a few basic rules for getting the desired maintainability of your test code.

Page objects themselves should never make verifications or assertions. This is part of your test and should always be within the test’s code, never in an page object. The page object will contain the representation of the page, and the services the page provides via methods but no code related to what is being tested should be within the page object.

There is one, single, verification which can, and should, be within the page object and that is to verify that the page, and possibly critical elements on the page, were loaded correctly. This verification should be done while instantiating the page object. In the examples above, both the SignInPage and HomePage constructors check that the expected page is available and ready for requests from the test.

The page object should return things like product name, product price, currently selected quantity, and so on. The test code would then assert that the returned string matches what is expected.

assert_message() would become getMessage() and return the message as a String. See below.

public String getMessage()
{
    return driver.findElement(messageLocator).getText();
}

(NOTE: read on for why I've changed the PageFactory element to a locator here.)

and then in your test code, you would have

Assert.assertEquals(editPost.getMessage(), "Post published. View post");

Now you've kept the assert code in your test script and out of the page object.

Looking at your code, I would make some further recommendations.

1. I would suggest you read up on some Java naming conventions. There are a number of sites that have recommendations and I think there are a lot of similarities between them but here's the oracle recommendations to start with. Your method names should be

   verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

   So assert_message() would turn into assertMessage() and so on. The _s make it look more like python.

2. Order of preference for locators: ID, CSS selector, and in rare circumstances, XPath. ID should always be your first choice because it (by W3C definition) should be unique on the page. CSS selector should be next because it's the fastest (in my testing faster than ID), has the best browser support, and is most consistently implemented across browsers. XPath should be reserved only for things that cannot be done by CSS seletors like finding an element by contained text. XPath locators are poor performers compared to CSS selectors and do not have the same level of support as CSS selectors. For example, your XPath locator can easily be converted to a CSS selector, "#message > p".

   Here are some CSS selector references to get you started.

   CSS Selectors reference

   CSS Selector tips

3. Drop PageFactory. Yes, it seems to make things easier but I think in many situations it causes more problems, like stale element exceptions and the like. Prefer instead to scrape the page as needed. Declare all locators at the top of the class and use them in methods when needed.

   public class EditPost {
   
       WebDriver driver;
   
       By messageLocator = By.cssSelector("#message > p")
   
       public EditPost(WebDriver editPostDriver)
       {
           this.driver = editPostDriver;
       }
   
       public String getMessage()
       {
           return driver.findElement(messageLocator).getText();
       }
   }
   

I know this is more than you asked but hopefully it's helpful.

The executeScript() method from the JavascriptExecutor Interface can invoke multiple arguments in the form of arguments[0], arguments[1], etc

• As per your example, to javaScriptExecutor.executeScript("arguments[0].click()", webElement); to work you need to have the webElement defined. executeScript() method will take the reference of the element as arguments[0] along with the method to be performed [in this case click()] and the reference should be provided thereafter.

  WebElement webElement = driver.findElement(By.xpath("xpath_element"));
  JavascriptExecutor javaScriptExecutor = (JavascriptExecutor)driver;
  javaScriptExecutor.executeScript("arguments[0].click()", webElement);
  

• Similarly, an example of executeScript() with multiple arguments[] is as follows :

  JavascriptExecutor js = (JavascriptExecutor) driver; 
  js.executeScript("arguments[0].setAttribute('style', arguments[1])", driver.findElement(By.xpath("//input[@type='file']")), "0");
  

  Here in this example :

  • driver.findElement(By.xpath("//input[@type='file'] is referred as arguments[0]
  • "0" is referred as arguments[1]

You can find a relevant discussion in What is arguments[0] while invoking execute_script() method through WebDriver instance through Selenium and Python?

This is how I got it to work finally !!

 driver.findElement(By.cssSelector("label[for='surveyForm\\:surveyUrlType\\:1']")).click()

The shade plugin combines all dependencies with the developed code and plops them in one Uber JAR. The downside is that it can overwrite resource files, and doesn't play well with signed jars (in my experience at least).

I would recommend moving away from the shade plugin if at all possible.

That said, if you have to use it - you're issue may be with the combining the jar resources. There are many transformers that you can use to resolve this, and you'll need to investigate which one is really needed. I would start with something like this

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.4.3</version>
    <configuration>
        <shadedArtifactAttached>true</shadedArtifactAttached>
        <shadedClassifierName>${executable.classifier}</shadedClassifierName>
        <filters>
            <filter>
                <artifact>*:*</artifact>
                <excludes>
                    <exclude>META-INF/*.SF</exclude>
                    <exclude>META-INF/*.DSA</exclude>
                    <exclude>META-INF/*.RSA</exclude>
                </excludes>
            </filter>
        </filters>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <transformers>
                    <transformer
                        implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
                    <transformer
                        implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>fully.qualified.ClassName</mainClass>
                    </transformer>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>

You can find more tranformers on the Apache plugin here

The alternative that I would suggest is Spring Boot, which uses the Jar-in-Jar structure with a custom ClassLoader to load classes from the internal jar(s).

This is the easier method due to not having to re-write files as the Shade plugin approach and it handles the dependencies a little better.

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>1.3.6.RELEASE</version>
    <configuration>
        <classifier>${executable.classifier}</classifier>
        <layout>ZIP</layout>
        <mainClass>fully.qualified.ClassName</mainClass>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>repackage</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Seriously, look at the simpler configuration!

NOTE: Most of this came from my own notes - version numbers may be a little old...

Try something this, Change the path and slashing accoding to your specifications :-

            WebDriver driver=null;
            System.setProperty("webdriver.chrome.driver","./src//lib//chromedriver");
            DesiredCapabilities capabilities = DesiredCapabilities.chrome();
            ChromeOptions options = new ChromeOptions();
            options.addArguments("test-type");
            options.addArgument("--start-maximized");
            options.addArguments("--disable-web-security");
            options.addArguments("--allow-running-insecure-content");
            capabilities.setCapability("chrome.binary","./src//lib//chromedriver");
            capabilities.setCapability(ChromeOptions.CAPABILITY, options);
            driver = new ChromeDriver(capabilities);
            driver.get("https://www.google.com/");

Below is the link where all available chrome flags are listed :-

http://peter.sh/experiments/chromium-command-line-switches/

Hope it will help you :)

Yes, that's the default behavior of TestNG and I had introduced it through that pull request to fix the bug https://github.com/cbeust/testng/issues/2022

To set the JVM arguments in intelliJ, choose Run > Edit Configurations, and add this JVM argument in the VM options section after -ea (which would be there by default.

For more information on editing configurations, please refer to the official documentation here

Added screenshot for easy to find in Intellij

Argument value

-ea -Dtestng.dtd.http=true

If the above does not work do at template level, this will fix it, which is

Run--> Edit configuration --> template --> testng