How to use getExtraCapability method of org.openqa.selenium.firefox.FirefoxOptions class

By definition, any widget that has focus also has the cursor. So driver.switchTo().activeElement() will return the currently focused WebElement. It doesn't actually change anything, just returns the active element. You can call

expectedElement.equals(driver.switchTo().activeElement());

to verify that expectedElement has focus.

Try this one:

(Java)

List<WebElement> childs = rootWebElement.findElements(By.xpath(".//*"));

(C#)

IReadOnlyList<IWebElement> childs = rootWebElement.FindElements(By.XPath(".//*"));

LE: I see quite a lot of people are interested in the full-page screenshot, so I thought I might update the answer with some positives (silver bullets).

There are quite a handful of web testing frameworks that can (with minimal setup & effort) produce a full-page screenshot. I come from a NodeJS testing environment, so I can only vouch the following: WebdriverIO & Google's Puppeteer.

If anyone is interested in an easy way to do it with WebdriverIO, check this answer.

Short answer is NO, YOU CANNOT, if you're only using Selenium (detailed reason bellow). But, what you can do is make the most out of your device's(monitor) viewport.

So, start your browser instance (driver) using ChromeOptions(), which is the method for setting ChromeDriver-specific capabilities. We can do the following:

• maximize the window (using the --start-maximized switch);
• go full-screen (F11-key on Windows, Control+Cmd+F on Mac, using the --start-fullscreen switch).
• Note: complete list of Chrome command-line-switches can be found here.

Your code should look like this:

// Setting your Chrome options (Desired capabilities)
ChromeOptions options = new ChromeOptions();
options.add_argument('--start-maximized');
options.add_argument('--start-fullscreen');

// Creating a driver instance with the previous capabilities
WebDriver driver = new ChromeDriver(options);

// Load page & take screenshot of full-screen page
driver.get("http://google.com");
File scrFile = ((TakesScreenshot)driver).getScreenshotAs(OutputType.FILE);

Now regarding the full page problem, all drivers (chromedriver, geckodriver, IEDriver, EdgeDriver, etc.) are implementing the WebDriver W3C standard. Thus, they are dependent on the way the WebDriver team wants to expose the functionality of different features, in our case, 'Take Screenshot'.

If you read the definition, it clearly states the following:

The Take Screenshot command takes a screenshot of the top-level browsing context’s VIEWPORT.

Legacy-wise, some drivers were able to produce a full-page screenshot (read more about it here), like the old FirefoxDriver, IEDriver, etc. That is no longer the case as they now all implement (to the letter) the WebDriver W3C standard.

Try this, it worked for me

DesiredCapabilities caps = new DesiredCapabilities();
caps.setJavascriptEnabled(true);                
caps.setCapability("takesScreenshot", true);  
caps.setCapability(
                        PhantomJSDriverService.PHANTOMJS_EXECUTABLE_PATH_PROPERTY,
                        "your custom path\\phantomjs.exe"
                    );
WebDriver driver = new  PhantomJSDriver(caps);

then rest of them are similar..and pls kindly comment your observation ,have a great day :)

If your tests are dependent, you can put them in the same class with dependsOnMethod={method1} defined on method2 so that the order is gauranteed. If it is between different classes, you might consider extending your AddNormalEE class from the LoginScript class.

To run tests in the same browser, your driver instance needs to be shared between your classes or it has to be the same in all your @Tests. Either make it static or consider having a threadlocal webdriver variable in case you plan to run parallely some day. In the above case, you can also have a method getDriver() in your loginScript which returns the driver object to the AddNormalEE class if static needs to be avoided.

As a general practice, it is good to have independent tests. You can make use of parallel runs to overcome the time issue with independent tests. Making login as a method and not a test since we are not asserting any behavior as per your code above. If I am testing login, I would have separate tests that test login functionality only.

To not see the logs in the console you can use the following:

System.setProperty("webdriver.gecko.driver","src/main/resources/drivers/geckodriver.exe");
System.setProperty(FirefoxDriver.SystemProperty.DRIVER_USE_MARIONETTE,"true");
System.setProperty(FirefoxDriver.SystemProperty.BROWSER_LOGFILE,"/dev/null");

return new FirefoxDriver();

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.

You have to install a Selenium Server (a Hub) and register your remote WebDriver to it. Then, your client will talk to the Hub which will find a matching WebDriver to execute your test.

You can have a look at here for more information.

Implicit Wait and Explicit Waits doesn't work that way, they will maximum wait for element for the time duration specified, If they find the element before that next step would be executed.

If you want your test to wait for exact time duration, you may want to use.

Thread.sleep(Time duration in milliseconds);

You may want to refer Diff b/w Implict Wait and Explicit Wait

Explicit Waits : An explicit waits is code you define to wait for a certain condition to occur before proceeding further in the code.

Implicit Waits : An implicit wait is to tell WebDriver to poll the DOM for a certain amount of time when trying to find an element or elements if they are not immediately available.

Thread.sleep : In sleep code It will always wait for mentioned seconds, even in case the page is ready to interact after 1 sec. So this can slow the tests.