How to use GET_ELEMENT_LOCATION_ONCE_SCROLLED_INTO_VIEW method of org.openqa.selenium.remote.Interface DriverCommand class

I had a similar issue couple of days ago. Apparently I was using an old version of selenium-node image. I updated to latest version and the issue was resolved.

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.

 webDriver.findElement(By.xpath("//a[@href='/docs/configuration']")).click();

The above line works fine. Please remove the space after href.

Is that element is visible in the page, if the element is not visible please scroll down the page then perform click action.

You can increase the timeout by modifying your script command. For instance, to increase the timeout to half an hour:

  - travis_wait 30 mvn package -Dtestng=test.xml

See Mor's answer for a great alternative that doesn't "hang" the build output for 30 minutes.

The basic authentication via url is blocked only for sub resources. So you could still use it on the domain:

driver.get("http://admin:admin@localhost:8080");
driver.get("http://localhost:8080/project");

You could also create a small extension to automatically set the credentials when they are requested:

options = webdriver.ChromeOptions()
options.add_extension(r'C:\dev\credentials.zip')

https://gist.github.com/florentbr/25246cd9337cebc07e2bbb0b9bf0de46

This is a common source of XPath confusion. First the straightforward parts:

• //a selects all a elements in the document.
• //a//b selects all b elements in the document that are descendants of a elements.

Normal stuff so far. Next is the tricky part:

1. To select the last b elements among siblings (beneath a elements):

   //a//b[last()]
   

   Here, the filtering is a part of the b selection criteria because [] has a higher precedence than //.

2. To select the last b element in the document (beneath a elements):

   (//a//b)[last()]
   

   Here, the last() is an index on the list of all selected b elements because () is used to override the default precedence.

You can run a single feature file by using cucumber.options which will override all the options you have in the @CucumberOptions annotation:

mvn test -Dcucumber.options="src/test/features/com/perspecsys/salesforce/featurefiles/Account.feature"

EDIT (Jun 2021): Subsequent versions removed the cucumber.options construct and replaced it. One way to achieve the same result now is through the use of tags. Place a tag on top of your feature file (example @feature_file_name) and then run the following command:

mvn test -Dcucumber.filter.tags='@feature_file_name'

Go with PhantomJS but if running them in chromedriver is required and you have the resources, this blog has a good recipe on running headless selenium with chrome. Requiring you to download the following...

• VirtualBox
• Vagrant
• NodeJS

If you plan to implement Jenkins or any other CI in the future, I strongly suggest going with PhantomJS though.

In my case, I have changed the tags from plugin to dependency like it is in the Maven Repository.

<dependency>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.8.1</version>
</dependency>