How to use afterFindBy method of org.openqa.selenium.support.events.Interface WebDriverEventListener class

Bohemian's answer is not flexible - you cannot have a page action returning you to the same page (such as entering a bad password), nor can you have more than 1 page action resulting in different pages (think what a mess you'd have if the Login page had another action resulting in different outcomes). You also end up with heaps more PageObjects just to cater for different results.

After trialing this some more (and including the failed login scenario), I've settled on the following:

private <T> T login(String user, String pw, Class<T> expectedPage){
    username.sendKeys(user);
    password.sendKeys(pw);
    submitButton.click();
    return PageFactory.initElements(driver, expectedPage);
}

public AdminWelcome loginAsAdmin(String user, String pw){
    return login(user, pw, AdminWelcome.class);
}

public CustomerWelcome loginAsCustomer(String user, String pw){
    return login(user, pw, CustomerWelcome.class);
}

public Login loginWithBadCredentials(String user, String pw){
    return login(user, pw, Login.class);
}

This means you can reuse the login logic, but prevent the need for the test class to pass in the expected page, which means the test class is very readable:

Login login = PageFactory.initElements(driver, Login.class);
login = login.loginWithBadCredentials("bad", "credentials");
// TODO assert login failure message
CustomerWelcome customerWelcome = login.loginAsCustomer("joe", "smith");
// TODO do customer things

Having separate methods for each scenario also makes the Login PageObject's API very clear - and it's very easy to tell all of the outcomes of logging in. I didn't see any value in using interfaces to restrict the pages used with the login() method.

I'd agree with Tom Anderson that reusable WebDriver code should be refactored into fine-grained methods. Whether they are exposed finely-grained (so the test class can pick and choose the relevant operations), or combined and exposed to the test class as a single coarsely-grained method is probably a matter of personal preference.

Element is not clickable at point (775.25, 10.166671752929688). Other element would receive the click:

It clearly says, the element we want to click is hidden by some other element div in this case, which would receive the click.

I think it is a problem with the UI and the header shouldn't hide the element, but you can try few things :

1. Maximize the window of the browser from webdriver to see if header still hides the element

   driver.manage().window().maximize() 
   

2. Use JavaScript to click element

   WebElement element = driver.findElement(By.<locator>);
   JavascriptExecutor executor = (JavascriptExecutor)driver;
   executor.executeScript("arguments[0].click()", element)`
   

You might consider running your script in HTMLUnitDriver - see short help about it

And at end of your code I would do check for some element which should be present after successful login and print out TRUE in case the driver finds it.

Cucumber features/scenarios are run in Alphabetical order by feature file name.

However, if you specifically specify features, they should be run in the order as declared. For example:

@Cucumber.Options(features={"automatedTestingServices.feature", "smoketest.feature"})

Another answer is not correct. There is also a vulnerability for version 1.x. CVE-2021-4104:

A flaw was found in the Java logging library Apache Log4j in version 1.x. JMSAppender in Log4j 1.x is vulnerable to deserialization of untrusted data. This allows a remote attacker to execute code on the server if the deployed application is configured to use JMSAppender and to the attacker's JMS Broker.

For the mitigation of this vulnerability:

These are the possible mitigations for this flaw for releases version 1.x:

• Comment out or remove JMSAppender in the Log4j configuration if it is used

• Remove the JMSAppender class from the classpath. For example:

  zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class
  

• Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker.

#getText()

getText() delivers the innerText of a WebElement.

Your input field does not have any inner Text. The text is found inside your value-attribute, hence accessing it via getAttribute("value") is the correct way to do it.

Based on your problem statement, the problem you are facing is that selenium is opening a fresh firefox profile where cookies are not enabled.

driver = new FirefoxDriver(); This is where you have to fix in such a way that it opens up a profile where cookies are enabled. One way is to create your own profile in firefox and open that profile instead of directly opening by FirefoxDriver();

ProfilesIni profileObj = new ProfilesIni();
FirefoxProfile yourFFProfile = profileObj.getProfile("your profile");
driver = new FirefoxDriver(yourFFProfile);

This way you can do what ever setting you need to in that profile and run your tests under that settings. If enabling cookies is the need, do that in firefox options.

Following is another way to open a specific profile as per seleniumhq.org

File profileDir = new File("path/to/top/level/of/profile");
FirefoxProfile profile = new FirefoxProfile(profileDir);
profile.addAdditionalPreferences(extraPrefs);
WebDriver driver = new FirefoxDriver(profile);

Check the source for more info on this topic. Source: http://docs.seleniumhq.org/docs/03_webdriver.jsp#modifying-the-firefox-profile

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

Many GWT elements comes with ensureDebugId (method on UIObject) to allow you to explicitly set Ids to elements for testing and debugging purpose. You also need to inherit the module

 <inherits name="com.google.gwt.user.Debug"/> 

to make it work. The advantage of this is, you can remove the trace from the production deployment by removing the inherited module in during prod mode compile. Hence there wont be code changes to remove unnecessary Ids.