How to use ErrorCodec class of org.openqa.selenium.remote package

Use findElements instead of findElement.

findElements will return an empty list if no matching elements are found instead of an exception.

To check that an element is present, you could try this

Boolean isPresent = driver.findElements(By.yourLocator).size() > 0

This will return true if at least one element is found and false if it does not exist.

The official documentation recommends this method:

findElement should not be used to look for non-present elements, use findElements(By) and assert zero length response instead.

1. They are tools to help you organize your tests. You can define what you want to run before/after tests, you can group your tests, and reporting on them is made easier.

2. It is usually mentioned with Selenium because Selenium is a common testing tool. The two work together well, but they are completely separate. (Selenium connects you to your browser, TestNG/JUnit organizes the tests)

3. Yes. You should be able to pick them up. They are designed to be fairly easy to learn.

Why to migrate? You can use JUnit for unit-testing and another framework for higher-level testing. In your case it is a kind of acceptance or functional or end-to-end, it is not that important how you name it. But important is to understand that these tests are not unit. They stick to different rules: they are more complex, run longer and less often, they require complex setup, external dependencies and may sporadically fail. Why not use another framework for them (or even another programming language)?

Possible variants are:

• BDD frameworks: already mentioned Cucumber, JDave, JBehave, Spock. For instance, Spock is JUnit based and Groovy =)
• TestNG

If adding another framework is not an option: you enumerated more options for JUnit then I could imagine =) I would put the whole test script for the flow in one test method and would organize test code into "Drivers". That means that your end-to-end tests do not call the methods of your application or Selenium API directly, but wrap them into methods of Driver components which hide API complexity and look like statements of what happens or what is expected. Look at the example:

@Test 
public void sniperWinsAnAuctionByBiddingHigher() throws Exception {
    auction.startSellingItem();

    application.startBiddingIn(auction);
    auction.hasReceivedJoinRequestFrom(ApplicationRunner.SNIPER_XMPP_ID);

    auction.reportPrice(1000, 98, "other bidder");
    application.hasShownSniperIsBidding(auction, 1000, 1098);

    auction.hasReceivedBid(1098, ApplicationRunner.SNIPER_XMPP_ID);

    auction.reportPrice(1098, 97, ApplicationRunner.SNIPER_XMPP_ID);
    application.hasShownSniperIsWinning(auction, 1098);

    auction.announceClosed();
    application.hasShownSniperHasWonAuction(auction, 1098);
} 

A snippet is taken from the "Growing Object-Oriented Software Guided by Tests". The book is really great and I highly recommend to read it.

This is real end-to-end test that uses real XMPP connection, Openfire jabber server and WindowLicker Swing GUI-testing framework. But all this stuff if offloaded to Driver components. And in your test you just see how different actors communicate. And it is ordered: after application started bidding we check that auction server received join request, then we instruct auction server to report new price and check that it is reflected in UI and so on. The whole code is available on github.

The example on github is complex, because the application is not as trivial as it usually happens with book examples. But that book gives it gradually and I was able to built the whole application from scratch following the book guide. In fact, it is the sole book I ever read on TDD and automated developer testing that gives such a thorough and complete example. And I've read quite a lot of them. But note, that Driver approach does not make your tests unit. It just allows you hide complexity. And it can (and should) be used with other frameworks too. They just give you additional possibilities to split your tests into sequential steps if you need; to write a user readable test cases; to externalize test data into CSV,Excel tables, XML files or database, to timeout your tests; to integrate with external systems, servlet and DI containers; to define and run separately test groups; to give more user-friendly reports and so on.

And about making all your tests unit. It is not possible for anything excluding something like utility libraries for math, string processing and so on. If you have application that is completely unit tested that it means either that you test not all application or you do not understand what tests are unit and what are not. The first case may be OK, but everything that is not covered must be tested and retested manually by developers, testers, users or whoever. It is quite common but it better to be conscious decision rather than casual one. Why you cannot unit test everything?

There are a lot of definitions of unit tests and it leads to holy war) I prefer the following: "Unit test is test for program unit in isolation". Some people say: "hey, unit is my application! I test login and it is simple unit function". But there is also pragmatics that hides in isolation. Why do we need to differ unit tests from others? Because it is our first safety net. They must be fast. You commit often (to git, for example) and you run them at least before each commit. But imagine, that "unit" tests takes 5 minutes to run. You will either run them less often or you will commit less often or you will run just one test case or even one test method at the time, or you will wait say each 2 minutes for tests to complete in 5 minutes. An in that 5 minutes you'll go to Coding Horror where you'll spend the next 2 hours =) And unit tests must never fail sporadically. If they do that - you will not trust them. Hence, the isolation: you must isolate slowness and sources of sporadic failures from your unit tests. Hence, isolation means that unit tests should not use:

• File system
• Network, Sockets, RMI and so on
• GUI
• Multithreading
• External libraries expecting test framework and supporting simple libraries like Hamcrest

And unit tests must be local. You want to have just one or so tests failing when you've made a defect within 2 minutes of coding, not a half of the whole suite. That means that you are very limited in testing stateful behavior in unit tests. You should not make a test setup that makes 5 state transitions to reach preconditions. Because fail in first transition will break at least 4 tests for following transitions and one more test that you currently write for the 6th transition. And any non-trivial application has quite a lot of flows and state transitions in it. So this cannot be unit tested. For the same reason unit tests must not use changeable shared state in database, static fields, Spring context or whatever. This is exactly the reason why JUnit creates new instance of test class for every test method.

So, you see, you cannot fully unit test a web app, no matter how you recode it. Because it has flows, JSPs, servlet container and probably more. Of course, you can just ignore this definition, but it is damn useful) If you agree that distinguishing unit tests from other tests is useful, and this definition helps to achieve that then you'll go for another framework or at least another approach for tests that are not unit, you'll create separate suites for separate kinds of test and so on.

Hope, this will help)

The browser cannot upload a file without an <input> element, unless the file is dropped from the desktop. It would be a security breach to be able to upload a file by code.

So in your case, the<input> is probably created once the user has clicked the link.

One way to handle this case is to silence the click event, click the link and then set the file to the <input>:

// disable the click event on an `<input>` file
((JavascriptExecutor)driver).executeScript(
    "HTMLInputElement.prototype.click = function() {                     " +
    "  if(this.type !== 'file') HTMLElement.prototype.click.call(this);  " +
    "};                                                                  " );

// trigger the upload
driver.findElement(By.id("Dialogs_Dialogs_lbAttachUpload"))
      .click();

// assign the file to the `<input>`
driver.findElement(By.cssSelector("input[type=file]"))
      .sendKeys("filepath\\Test PDF.pdf");

Note that you may also need to wait for the <input> to be created.

One other way to launch chrome in incognito mode is to add argument "-incognito" like following:

ChromeOptions options = new ChromeOptions();
options.addArguments("--incognito");
DesiredCapabilities capabilities = DesiredCapabilities.chrome();
capabilities.setCapability(ChromeOptions.CAPABILITY, options);

This solution works for me.

//Get Current Page 
String currentPageHandle = driver.getWindowHandle();                
linkToClick.click();        

//Add Logic to Wait till Page Load 

// Get all Open Tabs
ArrayList<String> tabHandles = new ArrayList<String>(driver.getWindowHandles());

String pageTitle = "ThePageTitleIhaveToCheckFor";
boolean myNewTabFound = false;

for(String eachHandle : tabHandles)
{
    driver.switchTo().window(eachHandle);
    // Check Your Page Title 
    if(driver.getTitle().equalsIgnoreCase(pageTitle))
    {
        // Report ur new tab is found with appropriate title 

        //Close the current tab
        driver.close(); // Note driver.quit() will close all tabs

        //Swithc focus to Old tab
        driver.switchTo().window(currentPageHandle);
        myNewTabFound = true;           
    }
}

if(myNewTabFound)
{
    // Report page not opened as expected       
}

As the exact answer for my own question "Selenium WebDriver get Current frame" I found the following way to do it.

JavascriptExecutor jsExecutor = (JavascriptExecutor)driver;
String currentFrame = jsExecutor.executeScript("return self.name");

But in here, the JavascriptExecutor execute the command every time to get the current frame. So if I consider the performance, I would like to choose #Saurabh Gaur's answer as the best answer . I hope my answer would be helpful to someone else :-)

Adding later

I Just did a small test, with my current version, with a global variable and with the js command help.

[Time collected (ms) on perfoming actions in 4 different elements in 2 nested iframes 1000 times. (4000 find element actions in total) ]

|          | Switch everytime | Global variable | JS command | 
|----------|------------------|-----------------|------------| 
|          | 2023             | 1950            | 2911       | 
|          | 1902             | 2091            | 2992       | 
|          | 2014             | 1974            | 3020       | 
|          | 1934             | 1931            | 3097       | 
|          | 1997             | 1965            | 3180       | 
|----------|------------------|-----------------|------------|
| Average  | 1974             | 1982.2          | 3040       | 

So the current performance with my "Switching default everytime" is not bad at all :D

I may not be able to talk about any standard pattern, but here are a few things that I consider:

1. Make good use of Test Execution frameworks. I use TestNG.
2. I create a base file which makes use of most of the TestNG annotations for Setting and Tearing up.
3. Separate your Re-usable functions and call it wherever needed. I generally add these in the base class.
4. I personally prefer keeping locators too in the base file if they are too complicated. This would help you to change the locator from one place and get reflected for all. In this case, do follow a good naming convention.
5. Use collections wherever possible.
6. You can use something like ReportNG for more user friendly reports.
7. Make more use of implicit waits and avoid using JavascriptExecutors.
8. Copy the Drivers and libraries within the project folders for better mobility and less external dependencies.
9. Adding selenium WD javadoc to your project will be of some help.
10. We also make sure we have a screenshot for failed test case by over-riding the onTestFailure method.
11. Rest all are simple coding basics for cleaner and easy to understand code that I believe you'll be following anyway.

Hope this was of some help. Will add more points if I'm able to recall. Also, please let me know if you need more details for any of these things.

Selenium supports org.openqa.selenium.JavascriptExecutor. We can get the value of window.performance.memory.usedJSHeapSize at any stage during testing. Below is the code.

  public static void reportMemoryUsage(WebDriver webDriver, String message) {
    ((JavascriptExecutor) webDriver).executeScript("window.gc()");
    try {
        TimeUnit.SECONDS.sleep(2);
    } catch (InterruptedException e) {
        LOGGER.error(e.getLocalizedMessage());
    }
    Double usedJSHeapSize = (Double) ((JavascriptExecutor) webDriver)
            .executeScript("return window.performance.memory.usedJSHeapSize/1024/1024");
    LOGGER.info("Memory Usage at " + message + " - " + usedJSHeapSize + " MB ");
 }

Call this method from your test suite, one at beginning of the test and one at the end. Difference between two usedJSHeapSize values will give the memory leak.

I am forcing garbage collection before taking usedJSHeapSize, to make sure the there is no garbage information collected. To enable gc function on window, you will have to set the -js-flags=--expose-gc option.

ChromeOptions options = new ChromeOptions();
options.addArguments("-js-flags=--expose-gc");
WebDriver webDriver = new ChromeDriver(options);