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.

You can do a nonblocking click by using either one of these:

The Advanced User Interactions API (JavaDocs)

WebElement element = driver.findElement(By.whatever("anything"));
new Actions(driver).click(element).perform();

or JavaScript:

JavascriptExecutor js = (JavascriptExecutor)driver;

WebElement element = driver.findElement(By.whatever("anything"));
js.executeScript("arguments[0].click()", element);

Below are possible ways to run Selenium test-cases from JMeter:

• using JUnit Request Sampler;
• using BeanShell Sampler;
• using JSR223 Sampler + Groovy.

JUnit Request Sampler

Running Selenium tests this way maybe useful if you want to re-use already automated (Java) Selenium scenarios instead of re-writing JS-scripts for WebDriver Sampler.

Selenium RC

---

1. Prepare Selenium test project and setup.

   1.1. Download Selenium Java client libraries and put selenium-java-${version}.jar to JMeter classpath, e.g. %JMETER_HOME%/lib/.
   1.2. Selenium server should be up and listening:

   java -jar selenium-server-standalone-${version}.jar
   

   1.3. Export Selenium test-plan as .jar and save it to %JMETER_HOME%/lib/junit/.

   NOTE: Your test class should extend TestCase or SeleneseTestCase to allow JMeter pick up this test plan, test case's name should start with "test").
   NOTE: By default SeleneseTestCase extends JUnit 3.x TestCase, also SeleneseTestCase expects external Selenium server to be running.

2. Configure JUnit Request sampler

   2.1. In JMeter test-plan add JUnit Request sampler.
   Set Class Name according to one from the Selenium test plan.
   Set Test Method to test that is about to run.
   Leave other parameters by default.

   

   JUnit 3.x vs. 4.x
   JUnit Request Sampler can process both JUnit3- and JUnit4-style classes and methods. To set Sampler to search for JUnit 4 tests (@Test annotations) check Search for Junit4 annotations (instead of JUnit 3) checkbox in settings above.
   The following JUnit4 annotations are recognized:

   @Test - used to find test methods and classes. The "expected" and "timeout" attributes are supported.
   @Before - treated the same as setUp() in JUnit3
   @After - treated the same as tearDown() in JUnit3
   @BeforeClass, @AfterClass - treated as test methods so they can be run independently as required

3. You are ready to start your Selenium test with JMeter.

Java code for JUnit Request sampler:

JUnit 3.x

package com.example.tests;

import com.thoughtworks.selenium.*;

public class selenium extends SeleneseTestCase {

    private static Selenium selenium;

    public void setUp() throws Exception {
        selenium = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.google.com/");
        selenium.start();
        selenium.windowMaximize();
    }

    public void testSelenium() throws Exception {
        selenium.open("/");
        selenium.waitForPageToLoad("30000");
        Assert.assertEquals("Google", selenium.getTitle());
    }

    public void tearDown() throws Exception {
        selenium.close();
    }
}

JUnit 4.x

Test script written in JUnit 4 uses JUnit annotations:

package com.example.tests;

import com.thoughtworks.selenium.*;

import org.junit.After;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;

public class selenium extends SeleneseTestCase {

    private static Selenium selenium;

    @Before
    public void setUp() throws Exception {
        selenium = new DefaultSelenium("localhost", 4444, "*firefox", "http://www.google.com/");
        selenium.start();
        selenium.windowMaximize();
    }

    @Test
    public void testSelenium() throws Exception {
        selenium.open("/");
        selenium.waitForPageToLoad("30000");
        Assert.assertEquals("Google", selenium.getTitle());
    }

    @After
    public void tearDown() throws Exception {
        selenium.stop();
    }
}

Selenium WebDriver

---

This case is an alternative to WebDriver Sampler mentioned in another answer below.

Prerequisites

The only difference with Selenium RC case is Selenium setup preparation:

1.1. Download and put selenium-server-standalone-${version}.jar to JMeter classpath, e.g. %JMETER_HOME%/lib/.
NOTE: There is no need to start the Selenium server.

All the other steps are the same as in the scenario described above.

package org.openqa.selenium.example;

import junit.framework.TestCase;

import org.junit.Before;
import org.junit.Test;
import org.junit.After;
import org.openqa.selenium.*;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.firefox.FirefoxProfile;

public class selenium extends TestCase {
    public static WebDriver driver;

    @Before
    public void setUp() {
        FirefoxProfile profile = new FirefoxProfile();
        driver = new FirefoxDriver(profile);
    }

    @Test
    public void testSelenium() throws Exception {
        driver.get("http://www.google.com/");
        Assert.assertEquals("Google", driver.getTitle());
    }

    @After
    public void tearDown() {
        driver.quit();
    }
}

---

Upd.

Another good points and step-by-step guides to use Selenium + JUnit + JMeter bundle:

• Integrating Selenium with JMeter for Load Testing
• Integrating Jmeter with Selenium Code
• Performance testing with Selenium and JMeter
• Running Selenium tests under JMeter
• How to integrate a JUnit4 – Webdriver test into JMeter

---

BeanShell Sampler

In this case selenium test-scenario is executed directly in JMeter's BeanShell Sampler.

1. Selenium setup preparation is completely identical to described above cases: download Selenium libraries, put to JMeter classpath, start Selenium server (in case of Selenium RC).
2. Put your selenium test-scenario into BeanShell Sampler:

Selenium RC

import com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

Boolean result = true;

try {
    selenium = new DefaultSelenium("localhost", 4444, "*iexplore", "http://www.google.com/");
    selenium.start();
    selenium.windowMaximize();

    selenium.open("/");
    selenium.waitForPageToLoad("30000");  

    if (!selenium.isTextPresent("Google")) result = false;
} catch (Exception ex) {
    ex.printStackTrace();
    IsSuccess = false;
    ResponseCode = "500";
    ResponseMessage = ex.getMessage();
} finally {
    selenium.stop();
}

IsSuccess = result;
return result;

Selenium WebDriver

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.htmlunit.HtmlUnitDriver;

Boolean result = true;

try {
    driver = new HtmlUnitDriver();
    driver.setJavascriptEnabled(true);

    driver.get("http://www.google.com/");

    if (!driver.getTitle().contains("Google")) result = false;
} catch (Exception ex) {
    ex.printStackTrace();
    IsSuccess = false;
    ResponseCode = "500";
    ResponseMessage = ex.getMessage();
} finally {
    driver.quit();
}

IsSuccess = result;
return result;

---

JSR223 Sampler + Groovy

In this case selenium test-scenario is executed via JSR223 Sampler + Groovy.
For performance considerations this approach seems to be more preferable than using BeanShell Sampler described above.

1. Selenium setup preparation is completely identical to described above cases: download Selenium libraries, put to JMeter classpath, start Selenium server (in case of Selenium RC).

2. Add Groovy support for JSR223 Sampler:

   2.1. download latest Groovy binary distribution;
   2.2. copy groovy-all-${VERSION}.jar from “embeddable” folder of distribution and drop it to %JMETER_HOME%/lib/;
   2.3. restart JMeter.

3. Configure JSR233 Sampler:

   3.1. add JSR233 Sampler to Thread Group;
   3.2. set Script Language to groovy in sampler's settings;
   3.3. put your selenium test-scenario into Script section (Java code will be accepted):

Selenium RC

import com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

Boolean result = true;

try {
    selenium = new DefaultSelenium("localhost", 4444, "*iexplore", "http://www.google.com/");
    selenium.start();
    selenium.windowMaximize();

    selenium.open("/");
    selenium.waitForPageToLoad("30000");      

    if (!selenium.isTextPresent("Google")) result = false;
} catch (Exception ex) {
    ex.printStackTrace();
    log.error(ex.getMessage());
     SampleResult.setSuccessful(false);
     SampleResult.setResponseCode("500");
     SampleResult.setResponseMessage(ex.getMessage());
} finally {
    selenium.stop();
}

SampleResult.setSuccessful(result);
return result;

Selenium WebDriver

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.htmlunit.HtmlUnitDriver;

Boolean result = true;

try {
    driver = new HtmlUnitDriver();
    driver.setJavascriptEnabled(true);

    driver.get("http://www.google.com/");

    if (!driver.getTitle().contains("Google")) result = false;
} catch (Exception ex) {
    ex.printStackTrace();
    log.error(ex.getMessage());
     SampleResult.setSuccessful(false);
     SampleResult.setResponseCode("500");
     SampleResult.setResponseMessage(ex.getMessage());
} finally {
    driver.quit();
}

SampleResult.setSuccessful(result);
return result;

---

Common notes for BeanShell / JSR223 Sampler cases:

• Use external .bsh / .groovy files with test-scenario (Script file field) instead of using Beanshell / Groovy code directly in sampler for intensive testing.
• Since BeanShell / JSR233 Samplers have access to JMeter's variables you can set test (= sampler execution) status directly in test-scenario (via e.g. IsSuccess = STATUS or SampleResult.setSuccessful(STATUS), see code above), without using Response Assertion.

The problem

The problem you are probably facing is that the method returns the right (and valid!) element, but when you're trying to access it a second later, it is stale and throws.

This usually arises when:

1. You click something that loads a new page asynchronously or at least changes it.
2. You immediatelly (before the page load could finish) search for an element ... and you find it!
3. The page finally unloads and the new one loads up.
4. You try to access your previously found element, but now it's stale, even though the new page contains it, too.

---

The solutions

There are four ways to solve it I know about:

1. Use proper waits

   Use proper waits after every anticipated page-load when facing asynchronous pages. Insert an explicit wait after the initial click and wait for the new page / new content to load. Only after that you can try to search for the element you want. This should be the first thing you'll do. It will increase the robustness of your tests greatly.

2. The way you did it

   I have been using a variant of your method for two years now (together with the technique above in solution 1) and it absolutely works most of the time and fails only on strange WebDriver bugs. Try to access the found element right after it is found (before returning from the method) via a .isDisplayed() method or something. If it throws, you already know how to search again. If it passes, you have one more (false) assurance.

3. Use a WebElement that re-finds itself when stale

   Write a WebElement decorator that remembers how it was found and re-find it when it's accessed and throws. This obviously forces you to use custom findElement() methods that would return instances of your decorator (or, better yet, a decorated WebDriver that would return your instances from usual findElement() and findElemens() methods). Do it like this:

   public class NeverStaleWebElement implements WebElement {
       private WebElement element;
       private final WebDriver driver;
       private final By foundBy;
   
       public NeverStaleWebElement(WebElement element, WebDriver driver, By foundBy) {
           this.element = element;
           this.driver = driver;
           this.foundBy = foundBy;
       }
   
       @Override
       public void click() {
           try {
               element.click();
           } catch (StaleElementReferenceException e) {
               // log exception
   
               // assumes implicit wait, use custom findElement() methods for custom behaviour
               element = driver.findElement(foundBy);
   
               // recursion, consider a conditioned loop instead
               click();
           }
       }
   
       // ... similar for other methods, too
   
   }
   

   Note that while I think that the foundBy info should be accessible from the generic WebElements to make this easier, Selenium developers consider it a mistake to try something like this and have chosen not to make this information public. It's arguably a bad practice to re-find on stale elements, because you're re-finding elements implicitly without any mechanism for checking whether it's justified. The re-finding mechanism could potentially find a completely different element and not the same one again. Also, it fails horribly with findElements() when there are many found elements (you either need to disallow re-finding on elements found by findElements(), or remember the how-manyeth your element was from the returned List).

   I think it would be useful sometimes, but it's true that nobody would ever use options 1 and 2 which are obviously much better solutions for the robustness of your tests. Use them and only after you're sure you need this, go for it.

4. Use a task queue (that can rerun past tasks)

   Implement your whole workflow in a new way!

   • Make a central queue of jobs to run. Make this queue remember past jobs.
   • Implement every needed task ("find an element and click it", "find an element and send keys to it" etc.) via the Command pattern way. When called, add the task to the central queue which will then (either synchronously or asynchronously, doesn't matter) run it.
   • Annotate every task with @LoadsNewPage, @Reversible etc. as needed.
   • Most of your tasks will handle their exceptions by themselves, they should be stand-alone.
   • When the queue would encounter a stale element exception, it would take the last task from the task history and re-run it to try again.

   This would obviously take a lot of effort and if not thought through very well, could backfire soon. I used a (lot more complex and powerful) variant of this for resuming failed tests after I manually fixed the page they were on. Under some conditions (for example, on a StaleElementException), a fail would not end the test right away, but would wait (before finally time-outing after 15 seconds), popping up an informative window and giving the user an option to manually refresh the page / click the right button / fix the form / whatever. It would then re-run the failed task or even give a possibility to go some steps back in history (e.g. to the last @LoadsNewPage job).

---

Final nitpicks

All that said, your original solution could use some polishing. You could combine the two methods into one, more general (or at least make them delegate to this one to reduce code repetition):

WebElement getStaleElem(By by, WebDriver driver) {
    try {
        return driver.findElement(by);
    } catch (StaleElementReferenceException e) {
        System.out.println("Attempting to recover from StaleElementReferenceException ...");
        return getStaleElem(by, driver);
    } catch (NoSuchElementException ele) {
        System.out.println("Attempting to recover from NoSuchElementException ...");
        return getStaleElem(by, driver);
    }
}

With Java 7, even a single multicatch block would be sufficient:

WebElement getStaleElem(By by, WebDriver driver) {
    try {
        return driver.findElement(by);
    } catch (StaleElementReferenceException | NoSuchElementException e) {
        System.out.println("Attempting to recover from " + e.getClass().getSimpleName() + "...");
        return getStaleElem(by, driver);
    }
}

This way, you can greatly reduce the amount of code you need to maintain.

I've struggled with the same problem over an hour and finally @kenorb's solution rescued me. To be short you need to add a browser extension that does the authentication for you (since Selenium itself can't do that!).

Here is how it works for Chrome and Python:

1. Create a zip file proxy.zip containing two files:

background.js

var config = {
    mode: "fixed_servers",
    rules: {
      singleProxy: {
        scheme: "http",
        host: "YOU_PROXY_ADDRESS",
        port: parseInt(YOUR_PROXY_PORT)
      },
      bypassList: ["foobar.com"]
    }
  };

chrome.proxy.settings.set({value: config, scope: "regular"}, function() {});

function callbackFn(details) {
    return {
        authCredentials: {
            username: "YOUR_PROXY_USERNAME",
            password: "YOUR_PROXY_PASSWORD"
        }
    };
}

chrome.webRequest.onAuthRequired.addListener(
        callbackFn,
        {urls: ["<all_urls>"]},
        ['blocking']
);

Don't forget to replace YOUR_PROXY_* to your settings.

manifest.json

{
    "version": "1.0.0",
    "manifest_version": 2,
    "name": "Chrome Proxy",
    "permissions": [
        "proxy",
        "tabs",
        "unlimitedStorage",
        "storage",
        "<all_urls>",
        "webRequest",
        "webRequestBlocking"
    ],
    "background": {
        "scripts": ["background.js"]
    },
    "minimum_chrome_version":"22.0.0"
}

2. Add the created proxy.zip as an extension

   from selenium import webdriver
   from selenium.webdriver.chrome.options import Options
   
   chrome_options = Options()
   chrome_options.add_extension("proxy.zip")
   
   driver = webdriver.Chrome(executable_path='chromedriver.exe', chrome_options=chrome_options)
   driver.get("http://google.com")
   driver.close()
   

That's it. For me that worked like a charm. If you need to create proxy.zip dynamically or need PHP example then go to the original post

First of all, I apologise because I had never worked on a grid before. I thought it will be a frame and will be easier to switch and then scroll to the element using JavascriptExecutor. But, alas! That's not the case for a grid.
And, there must be a table when a grid is involved.

Now, this is what has worked for me.

First click on any visible element on grid to get it into focus.

Then scroll the grid using grid's locator(xpath,id,etc.) using 'Keys.PAGE_DOWN' till you find the element you are looking for.

In case the element is not found on each scrolls, than handle the exception it raises and scroll again.

Note: Do not forget to give some sleep time after each scroll.

I have automated one sample grid, and have attached the sample working code below. Hope this helps in figuring out problem:

import java.io.IOException;

import org.openqa.selenium.By;
import org.openqa.selenium.JavascriptExecutor;
import org.openqa.selenium.Keys;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;

public class ScrollGrid{

    public static void main(String[] args) throws IOException, InterruptedException{


        WebDriver driver = new FirefoxDriver();
        driver.get("https://demos.devexpress.com/ASPxGridViewDemos/PagingAndScrolling/VirtualPaging.aspx");
        driver.manage().window().maximize();

        //Clicking on an element inside grid to get it into focus
        driver.findElement(By.xpath("//*[@id='ContentHolder_ASPxGridView1_DXMainTable']//td[.='9/30/1994']")).click();

        WebElement ele=null;
        int flag=0;
        int count=0;

        do{
            try{
                //element to search for while scrolling in grid
                ele = driver.findElement(By.xpath("//*[@id='ContentHolder_ASPxGridView1_DXMainTable']//td[.='3/28/1996']"));
                flag=1;
            } catch(Throwable e){
                //scrolling the grid using the grid's xpath
                driver.findElement(By.xpath("//*[@id='ContentHolder_ASPxGridView1']//div[2]")).sendKeys(Keys.PAGE_DOWN);
                Thread.sleep(3000);
            }
        }while((flag==0) || ((++count)==250));

        if(flag==1){
            System.out.println("Element has been found.!!");
        }else{
            System.out.println("Element has not been found.!!");
        }

        highlightElement(driver, ele); //For highlighting the element
        Thread.sleep(5000L); //to check if the element scrolled to is highlighted.
        driver.close();
    }

    //For highlighting the element to be located after scroll
    public static void highlightElement(WebDriver driver, WebElement ele) {
        try
        {
            for (int i = 0; i < 3; i++) 
            {
                JavascriptExecutor js = (JavascriptExecutor) driver;
                js.executeScript("arguments[0].setAttribute('style', arguments[1]);",ele, "color: red; border: 2px solid red;");
            }
        }
        catch(Throwable t)
        {
            System.err.println("Error came : " +t.getMessage());
        }
    }

}

Note: This works correctly now. It will come out of the loop in case the element is found, or if not found after 250 scrolls. '250' is a relative number. You can change it to the number of scrolls you want to perform on the grid.

Add this to the options you pass to the driver:

options.addArguments("disable-infobars");

Unfortunately Selenium WebDriver 2.53.0 is not compatible with Firefox 47.0. The WebDriver component which handles Firefox browsers (FirefoxDriver) will be discontinued. As of version 3.0, Selenium WebDriver will need the geckodriver binary to manage Firefox browsers. More info here and here.

Therefore, in order to use Firefox 47.0 as browser with Selenium WebDriver 2.53.0, you need to download the Firefox driver (which is a binary file called geckodriver as of version 0.8.0, and formerly wires) and export its absolute path to the variable webdriver.gecko.driver as a system property in your Java code:

System.setProperty("webdriver.gecko.driver", "/path/to/geckodriver");

Luckily, the library WebDriverManager can do this work for you, i.e. download the proper Marionette binary for your machine (Linux, Mac, or Windows) and export the value of the proper system property. To use this library, you need to include this dependency into your project:

<dependency>
    <groupId>io.github.bonigarcia</groupId>
    <artifactId>webdrivermanager</artifactId>
    <version>5.1.0</version>
</dependency>

... and then execute this line in your program before using WebDriver:

WebDriverManager.firefoxdriver().setup();

A complete running example of a JUnit 4 test case using WebDriver could be as follows:

public class FirefoxTest {

    protected WebDriver driver;

    @BeforeClass
    public static void setupClass() {
        WebDriverManager.firefoxdriver().setup();
    }

    @Before
    public void setupTest() {
        driver = new FirefoxDriver();
    }

    @After
    public void teardown() {
        if (driver != null) {
            driver.quit();
        }
    }

    @Test
    public void test() {
        // Your test code here
    }
}

Take into account that Marionette will be the only option for future (for WebDriver 3+ and Firefox 48+), but currently (version 0.9.0 at writing time) is not very stable. Take a look to the Marionette roadmap for further details.

UPDATE

Selenium WebDriver 2.53.1 has been released on 30th June 2016. FirefoxDriver is working again with Firefox 47.0.1 as browser.

Using Geb at our workplace has been a life-saver. I can't imagine this many people (with absolutely no programming background) picking up Selenium in as short a time span.

I've been very successful creating mavenized geb projects that we have running on Jenkins for our CI. It does have a few limitations like not having the drag and drop ability right out of the box. However, you are always free to use the Selenium APIs whenever the need arises. Also, to the commenter about it lacking the support for phantomJS - says who? You can use absolutely any driver that selenium supports. Check this link for details.