How to use getImplementation method of org.openqa.selenium.remote.html5.AddApplicationCache class

There are several things you can try:

• an Explicit elementToBeClickable Wait:

  WebDriverWait wait = new WebDriverWait(webDriver, 10);
  
  WebElement button = wait.until(ExpectedConditions.elementToBeClickable(By.id("myid")));
  button.click()
  

• move to element before making a click:

  Actions actions = new Actions(driver);
  actions.moveToElement(button).click().build().perform();
  

• make the click via javascript:

  JavascriptExecutor js = (JavascriptExecutor)driver;
  js.executeScript("arguments[0].click();", button);
  

You can do this by finding the x and y coordinates of the checkbox in reCAPTCHA and click the element.

WebElement captcha = driver.findElement(By.xpath("html/body/div[1]/div[3]/div[2]/form/div[5]/div"));
        builder.moveToElement(captcha, 50, 30).click().build().perform();

As long as I know that the java command

WebDriver driver = new FirefoxDriver();

will run the installed Firefox browser on your computer.

but reading the JavaDoc at I realised that there can be way how to override it:

FirefoxBinary binary = new FirefoxBinary(new File("path/to/binary"));
FirefoxProfile profile = new FirefoxProfile();
WebDriver driver = new FirefoxDriver(binary, profile);

On Linux, you can start up a vncserver on a different display (say, :8 or something) and then have Selenium and your Firefox instances use that display. Works well for us where I work.

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...

The fact that PhantomJS keeps sessions between tests is a known problem in GhostDriver, the Selenium Webdriver implementation in PhantomJS.

I suppose that this problem will be fixed with the PhantomJS 2 release. The bug is already fixed in GhostDriver 1.1.1, but there is no PhantomJS version which includes this GhostDriver version.

The issue comes from conflicting Guava (transitive dependency) versions.

It should be fixed with the WebDriverManager version 5.1.0.

As an alternative, you can also use the <dependencyManagement> section of your pom.xml to force a resolution of the latest Guava version:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>31.0.1-jre</version>
    </dependency>
  </dependencies>
</dependencyManagement>

or exclude the Guava dependency from the WebDriverManager (no longer required for >= 5.1.0):

<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.0.3</version>
    <exclusions>
        <exclusion>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
        </exclusion>
    </exclusions>
</dependency>

PS: To ensure dependency convergence for your Maven project, consider adding the Maven Enforcer Plugin to detect multiple versions of the transitive dependency early on.

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.

selenium.`type`("ab","abc")