In order to use ChromeDriver undetectable to Distil checkpoints (which are described nicely in this stackoverflow post), you will need to ensure that your browser does not contain any variable in its window or document prototypes that reveal that you are using a webdriver, as the one you mention.

You can use software as Selenium along with ChromeDriver and Chrome as long as you take some precautions and make some fixes to the binaries. This method will apply only to headed version, if you wish to use headless, you would need to take additional measurements to pass window/rendering tests, described here.

1. Fix Chrome binary, or use an old version

First, lets deal with that navigator.webdriver set to True. This is defined by W3C protocol here as part of 'NavigatorAutomationInformation' of browsers, which extends the Navigator interface. How to remove it? That project has a lot of files, third party stuff, blink web runtimes, etc. So, instead of becoming crazy trying to figure out how this works, as Chromium is open-source, just be clever and search google for the commit which incorporated that. Here is the link. Pay attention to these files:

• third_party/WebKit/Source/core/frame/Navigator.h, which holds the line of code:

   `bool webdriver() const { return true; }` 
  
  This method is supossed to always return true, as you can see.
  

• third_party/WebKit/Source/core/frame/Navigator.idl, which contains the extensions of Navigators, included our

  `Navigator implements NavigatorAutomationInformation;` 
  
  which is being commited. Interesting, isn't it?
  

• third_party/WebKit/Source/core/frame/NavigatorAutomationInformation.idl contains the extension itself, with a read-only variable, which is webdriver:

       `[
           NoInterfaceObject, // Always used on target of 'implements'
           Exposed=(Window),
           RuntimeEnabled=AutomationControlled
       ] interface NavigatorAutomationInformation {
           readonly attribute boolean webdriver;
       };`
  

To get rid of this functionality, it should be enough commenting the line in Navigator.idl which extends Navigator with this functionality, and compile the source (compiling in linux here). However, this is a laborious task for almost any computer and can take several hours. If you look the date of the commit, it was on Oct 2017, so an option is to download any version of Chrome released before that date. To search for mirrors, you can google for inurl:/deb/pool/main/g/google-chrome-stable/.

2. Fix ChromeDriver

Distil checks the regex rule '/\$[a-z]dc_/' against window variables, and ChromeDriver adds one as mentioned here which satisfies that condition. As they mention, you have to edit call_function.js amongst the source code, and redefine the variable var key = '$cdc_asdjflasutopfhvcZLmcfl_';. with something else. Also, probably easier, you can use an hex editor to update the existing binary.

If you decided to use an older version of Chrome -I guess you did-, you will need to use an appropiate version of ChromeDriver. You can know which one is fine for your Chrome version in the ChromeDriver downloads webpage. For example, for Chrome v61 (which fits your needs), you could use ChromeDriver 2.34. Once done, just put the ChromeDriver binary on '/usr/bin/local'.

3. Take other precautions

• Pay attention to your user-agent.
• Don't perform too many repeated requests.
• Use a (random) delay between requests.
• Use the Chrome arguments used here to mimic a normal user profile.

Check if your code's NoSuchElementException is of type org.openqa.selenium.NoSuchElementException.

It is very likely that you might have used java.util.NoSuchElementException instead.

You could try adding import org.openqa.selenium.NoSuchElementException on top of your source code.

You can also check pageloaded using following code

IWait<IWebDriver> wait = new OpenQA.Selenium.Support.UI.WebDriverWait(driver, TimeSpan.FromSeconds(30.00));

 wait.Until(driver1 => ((IJavaScriptExecutor)driver).ExecuteScript("return document.readyState").Equals("complete"));

I have noticed that in my case and worked perfectly.You need add window size as an arguments in headless Mode.I don't know which language you are working on.

If you are using python add this .

  chrome_options = webdriver.ChromeOptions()
  chrome_options.add_argument('--headless')
  chrome_options.add_argument('window-size=1920x1080')

if you are using java add this.

ChromeOptions chromeOptions = new ChromeOptions();
chromeOptions.addArguments("headless");
chromeOptions.addArguments("window-size=1920,1080");

Please try this and let me know if this work.

Create a new implementation of FieldDecorator.

When you use the PageFactory you are probably calling

 public static void initElements(ElementLocatorFactory factory, Object page)

This would become

 public static void initElements(FieldDecorator decorator, Object page)

Your FieldDecorator could behave similarly to the DefaultFieldDecorator except wrap the proxy in your custom type.

See the classes here [source]

If I understand your needs correctly this can be achieved by combining the following:

• using a JUnit method rule which will give you the name of the current method
• creating a Log4j appender at runtime, and configuring it with the name of the method obtained you just obtained

Specifically, you need to create a custom JUnit rule. I chose to extend the TestWatcher as it seems most appropriate

import java.io.File;
import java.io.IOException;
import java.text.SimpleDateFormat;
import java.util.Date;

import org.apache.log4j.Logger;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.RollingFileAppender;
import org.junit.rules.TestWatcher;
import org.junit.runner.Description;

public class TestMethodLogging extends TestWatcher {
  private static final String date = new SimpleDateFormat("y-MM-dd")
      .format(new Date());
  private Logger logger;

  @Override
  protected void starting(Description description) {
    String name = description.getMethodName();
    RollingFileAppender a = (RollingFileAppender) Logger.getRootLogger()
        .getAppender("rollingFile");
    PatternLayout layout = new PatternLayout();
    layout.setConversionPattern("%d{dd MMM yyyy HH:mm:ss} %p %t %c - %m%n");

    try {
      File logDir = new File(a.getFile()).getParentFile();
      File logFile = new File(logDir, name + "_" + date);
      logger = Logger.getLogger(name);
      logger.addAppender(new RollingFileAppender(layout, logFile
          .getAbsolutePath()));
    } catch (IOException e) {
      throw new RuntimeException(e);
    }
  }

  public Logger getLogger() {
    return logger;
  }
}

Once you have this you can place it as a rule inside your test class. A rule is simply a field in the test (carrying the @Rule annotation). In here I called it rule (not very imaginative, I admit). In order to log from your test method you need to call rule.getLogger().

import static org.junit.Assert.assertEquals;

import org.junit.Rule;
import org.junit.Test;

public class MyTest {
  @Rule
  public TestMethodLogging rule = new TestMethodLogging();

  @Test
  public void sumOfTwoInts() throws Throwable {
    rule.getLogger().error(
        "logging to a logger whose name is based on the test method's name");
    assertEquals(5, 2 + 3);
  }

  @Test
  public void productOfTwoInts() throws Throwable {
    rule.getLogger().error(
        "logging to a logger whose name is based on the test method's name");
    assertEquals(8, 2 * 4);
  }
}

When I run this test it creates these two files under my ~/Desktop/Selenium/AutomationLogs directory:

productOfTwoInts_2015-05-10  
sumOfTwoInts_2015-05-10

The content of the first file looks as follows:

$ cat productOfTwoInts_2015-05-10 
10 May 2015 19:59:58 ERROR main productOfTwoInts - logging to a logger whose name is based on the test method's name
10 May 2015 20:01:22 ERROR main productOfTwoInts - logging to a logger whose name is based on the test method's name
10 May 2015 20:01:24 ERROR main productOfTwoInts - logging to a logger whose name is based on the test method's name

Try element.getAttribute("value")

The text property is for text within the tags of an element. For input elements, the displayed text is not wrapped by the <input> tag, instead it's inside the value attribute.

Note: Case matters. If you specify "Value", you'll get a 'null' value back. This is true for C# at least.

In Selenium 2.0, if you are using WebDriver to drive the tests in the browser, you can use the WebDriver.TargetLocator class to get the element in focus, in a window/frame:

WebDriver driver = ... // initialize the driver
WebElement currentElement = driver.switchTo().activeElement();

If no element is in focus, the active element would turn out to be the body of the document being displayed, which might be the case when you launch a new page, for instance. When you invoke methods like click, sendKeys etc. you'll find the WebElement returned by the above invocation will always represent the element in focus.

This was tested using FirefoxDriver, and I would suspect that the same would be true of other drivers, except for the HtmlUnitDriver and similar drivers that do not use a full-fledged browser under the hood.

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.