How to use RemoteSession class of org.openqa.selenium.grid.session.remote package

Here is how I am sending character by character using Selenium Webdriver (in Java). This way in the back-end, I verify at each letter press if the character exists in the input. Normal element.sendKeys() is not working well for me 2 out of 5 times - the last letter is missing, I guess something is buggy with Selenium Webdriver, I don't know. Try the code below, it works 100% of the time for me.

public void TypeInField(String xpath, String value){
    String val = value; 
    WebElement element = driver.findElement(By.xpath(xpath));
    element.clear();

    for (int i = 0; i < val.length(); i++){
        char c = val.charAt(i);
        String s = new StringBuilder().append(c).toString();
        element.sendKeys(s);
    }       
}

As you see, I get the value needed to be typed and in the for loop, I take each character, convert it to string and send it to textbox. Also, I have a search for xpath, you can change that to id, or classname, or whatever you want.

BrowserStack provides the Local testing feature to test the internal websites which are not accessible publicly. Local testing feature is enabled by setting the capability 'browserstack.local' to the value 'true' and starting the BrowserStackLocal binary.

Have you started the BrowserStackLocal binary? You can start the binary by executing the following command in your command prompt-

BrowserStackLocal.exe --key ACCESS_KEY

The error - '[browserstack.local] is set to true but local testing through BrowserStack is not connected.' usually occurs when the BrowserStackLocal binary is not running.

I can think of the following causes for the error-

1. When the test script and BrowserStackLocal binary connection do not use the same username and access key. You can verify the username and access key associated with your account here, https://www.browserstack.com/accounts/settings

2. When the test script and BrowserStackLocal binary connection do not use the same local identifier

3. When a new BrowserStackLocal binary is invoked with the same parameters and hence the old connection is closed thereby displaying the error
4. Binary disconnected at your end due to some network connectivity issues

You can make sure that the test script and the BrowserStackLocal binary uses the same access key and the same local identifier, in case, if you are using a Local Identifier for the BrowserStackLocal binary connection. Also, make sure that all the old connections of BrowserStackLocal binary are terminated before starting a new one with the same parameters. Read more on Local testing here, https://www.browserstack.com/local-testing.

If anyone actually knew a general and always-applicable answer, it would have been implemented everywhere ages ago and would make our lives SO much easier.

There are many things you can do, but every single one of them has a problem:

1. As Ashwin Prabhu said, if you know the script well, you can observe its behaviour and track some of its variables on window or document etc. This solution, however, is not for everyone and can be used only by you and only on a limited set of pages.

2. Your solution by observing the HTML code and whether it has or hasn't been changed for some time is not bad (also, there is a method to get the original and not-edited HTML directly by WebDriver), but:

   • It takes a long time to actually assert a page and could prolong the test significantly.
   • You never know what the right interval is. The script might be downloading something big that takes more than 500 ms. There are several scripts on our company's internal page that take several seconds in IE. Your computer may be temporarily short on resources - say that an antivirus will make your CPU work fully, then 500 ms may be too short even for a noncomplex scripts.
   • Some scripts are never done. They call themselves with some delay (setTimeout()) and work again and again and could possibly change the HTML every time they run. Seriously, every "Web 2.0" page does it. Even Stack Overflow. You could overwrite the most common methods used and consider the scripts that use them as completed, but ... you can't be sure.
   • What if the script does something other than changing the HTML? It could do thousands of things, not just some innerHTML fun.

3. There are tools to help you on this. Namely Progress Listeners together with nsIWebProgressListener and some others. The browser support for this, however, is horrible. Firefox began to try to support it from FF4 onwards (still evolving), IE has basic support in IE9.

And I guess I could come up with another flawed solution soon. The fact is - there's no definite answer on when to say "now the page is complete" because of the everlasting scripts doing their work. Pick the one that serves you best, but beware of its shortcomings.

This is not a Selenium issue, pressing enter in a text field often submits the form. Usually you can bypass it by using Shift+Enter to insert a new line. Try this:

String myText = "first line\nsecond line";
myText = myText.replace("\n", Keys.chord(Keys.SHIFT, Keys.ENTER));
myElement.sendKeys(myText);

I was looking for something similar just recently and found that the Changelog is probably the best place to look at for compatibility questions:

https://github.com/SeleniumHQ/selenium/blob/master/java/CHANGELOG

(used to be at when Selenium was hosted on Google Code).

All the most recent version have a support up to Firefox v XX comment at the very top of each version. The older ones you have to read in the comments a little, but they will say which version is the greatest supported for that release.

Hope this helps.

Make sure you do this. Note sure if you are using Gradle, Maven or ANT. But the following concept is very similar to any build system.

1. You must be having a .war/.ear app artifact that you need to run behind Tomcat / similar.
   • You also need to make sure that you compiled your main code in debug mode, or jacoco will not be happy.
   • For ex: -g option in Java and similar debug option (if you are using groovy).

tasks.withType(Compile) {
    options.debug = true
    options.compilerArgs = ["-g"]
}

2. Lets say you have the .war and using Tomcat. Then while starting Tomcat.
   • In Tomcat start script, make sure you are telling Tomcat's JVM where's jacocoagent.jar file and passing other parameters. THIS is the MAIN missing point sometime we see (aka not attaching jacoco to target JVM's session and trying to get code coverage).

For ex: I start my Tomcat script with the following parameter passed to Tomcat (-Dxxxx=value way)

PROJ_EXTRA_JVM_OPTS=-javaagent:tomcat/jacocoagent.jar=destfile=build/jacoco/ST/jacocoST.exec,append=false

Basically, Tomcat start script would have -Dparameter=value, you can pass the above parameter (Linux/Unix export the variable) to Tomcat/Target JVM's scope.

The above parameter line when sent to Tomcat, will attach JACOCO agent .jar file to the "TARGET" (aka Tomcat JVM). Here you are telling Tomcat that go look for jacocoagent.jar file from a director called "tomcat" under your workspace. It's gonna create a jacoco .exec file named "jacocoST.exec" (aka jacoco exec file for Selenium Test) under build/jacoco/ST folder (I'm using Gradle so Gradle creates "build" folder anytime you run a build/compile/test/integrationTest/customSeleniumTaskThatYouMightHaveCreated).

NOTE: This means, that you DON'T have to specify jacoco section in the test task (as that'll run in your BUILD systems' JVM either Gradle or Maven or ANT whatever you have).

//We don't need jacoco for non-unit tests type of tasks as Jacoco won't be able to find any coverage if done this way. Jacoco agent file needs to be attached/visible to the TARGET's JVM (where you run your application via a .war / .ear etc).

jacoco { 
  //  ... As Gradle runs Unit tests (while doing build), they run free, in the same JVM where Gradle runs the build so Unit test have visibility to the main classes in the same JVM (which Gradle is using to run the build). Thus, you can use jacoco section in Gradle for running unit tests. BUT,
  // ... Don't use this section for running Integration, Acceptance, Selenium tests which run on a target JVM. Instead attach jacocoagent.jar and specify jacoco parameters to the target JVM.
}

3. Once you have your Tomcat up and running, now you run your Selenium tests. NOTE: -- I'm using Jenkins on Linux/Unix machine and "xvfb" plugin is very handy i.e. now I can run Selenium GUI tests in HEADLESS mode and I won't bug any user on a machine where the tests are running by popping up the tests pages while the GUI tests are running.

   -- if you end up using "xvfb" plugin in Jenkins, you FIRST need to start "Xvfb" service on the server (Linux/Unix) where you are running the tests.

   -- If you are running your non-units tests (aka Integration/Selenium etc) on a Windows machine, then you can see the GUI tests pop up when you run your tests. If you don't want to see the popup windows, then your Jenkins instance can run the slave (your windows machine) process as a service ("Install as a Service"). If you create your windows machine as a slave, when you run the JLNP installation on your machine, You'll see a popup that Jenkins has successfully started a slave process, clicking File > Install as a service will run your slave on a windows machine as "HEADLESS".

4. While your tests are running, you'll notice that this time, jacoco will create a folder structure/exec file as per your defined value for destfile parameter but it'll still be 0 or some small size.

5. Once your Selenium/non-unit tests are complete, you have to "STOP" Tomcat / target JVM. This will FLUSH all jacoco coverage info to this jacocoST.exec file (custom file that you wanted jacoco to create). -- Note: If you want jacocoST.exec file to be flushed on the fly (without requiring the Tomcat JVM/session to stop, then you can look into jacoco documentation how to do that, there is one topic there which tells about this, this way your application can continue to run and you dont have to stop your application/webservice).

6. Run jacocoTestReport task and you'll see jacoco code coverage.

   • Make sure you specify where are your sources/classes for main code.

for ex:

  jacocoTestReport {
      group = "Reporting"
      description = "Generate Jacoco coverage reports after running tests."
      ignoreFailures = true


      //UT=is for Unit tests, IT=integrationTest, AT=acceptanceTest, ST=Selenium GUI tests.
      //executionData = files('build/jacoco/UT/jacocoUT.exec')
      //executionData = files('build/jacoco/IT/jacocoIT.exec')
      //executionData = files('build/jacoco/UT/jacocoUT.exec', 'build/jacoco/IT/jacocoIT.exec')

      //executionData = files(['build/jacoco/UT/jacocoUT.exec', 'build/jacoco/IT/jacocoIT.exec'])
      //OR use the following way for all.
      executionData = fileTree(dir: 'build/jacoco', include: '**/*.exec')

      reports {
             xml{
                 enabled true
                 //Following value is a file
                 destination "${buildDir}/reports/jacoco/xml/jacoco.xml"
             }
             csv.enabled false
             html{
                 enabled true
                 //Following value is a folder
                 destination "${buildDir}/reports/jacoco/html"
             }
      }

      //sourceDirectories = files(sourceSets.main.allJava.srcDirs)
      sourceDirectories = files('src/java')
      //sourceDirectories = files(['src/java','src/groovy'])
      classDirectories =  files('build/classes/main')

      //------------------------------------------
      //additionalSourceDirs = files(['test/java','test/groovy','src/java-test', 'src/groovy-test'])
      //additionalSourceDirs += files('src/java-test')
}

Feel free to ping me if you still see any issues. You can also see few of my posts here on stackoverflow on how I achieved this and also publishing the same coverage to SonarQube.

You may be able fake it by setting the WebDrivers PageLoadTimeout to zero.

In C# this worked for me:

driver.Manage().Timeouts().SetPageLoadTimeout(new TimeSpan(0));

I'm Guessing in Java it would be something like this:

driver.manage().timeouts().pageLoadTimeout(0, TimeUnit.SECONDS);

After you're done doing that you could turn it back up to 30 seconds or something as some posts have indicated the default is.

Source for the pageLoadTimeout: https://selenium.googlecode.com/git/docs/api/java/org/openqa/selenium/WebDriver.Timeouts.html

And the default time: https://sqa.stackexchange.com/questions/2606/what-is-seleniums-default-timeout-for-page-loading

One of the differences between Katalon and groovy is that groovy is lightweight as compared to Katalon. Since Katalon offers variety of features in a container, it is easier to use. Scripting is very much encapsulated within it. Groovy on other had provides many features for testing - Do check out Spock (http://spockframework.org) which is mainly used for testing Java/Groovy applications.

In a nut shell; which should be chosen really depends on the team composition of programmers, tech stack on which your app is built, maintainability of the application in scope. Hope it helps...

My idea to solve this...

Create Firefox Profiles and open them with Selenium. You can modify them for your needs.

Selenium Documentation

By using specific profiles you can avoid this issue. It is not a "nice and clean" Solution..but it works...at least for me.