Jan 9, 2018
Parallel Testing with Selenium Webdriver
Erin Bailey
Read More
The combination of using JMeter and some simple scripting to invoke Selenium code allows you to measure how fast HTML pages take to load. And with Headless browser execution, the test execution time can be reduced up to 30% and lets you continue to use your computer while the tests execute in the background.
Find out why performance testing is essential in establishing an exceptional customer experience. Contact Kobiton Today!
As Web driver restricts our ability to scale due to its high usage of CPU, combining it with a well-organized JMeter load Test helps.
One of the most significant advantages we have here is achieving the performance matrix by avoiding multiple browsers opening up and minimizing the overall CPU usage and speed.
There are two primary ways to achieve this integration:
- We can do client-side performance analysis using ‘Web driver Samplers’ in JMeter using Selenium/Web driver Support Plugin
- Selenium Scripts, which are already created, using Eclipse IDE can be integrated by exporting Selenium scripts jars and placing the jars in lib Junit folder
The Tools Behind the Integration
Before we get into the mechanics, it helps to be clear on what each tool actually does — and why they’re stronger together.
What is JMeter?
Apache JMeter is an open-source, Java-based load-testing tool. It’s best known for simulating heavy traffic against web servers, but it’s far more versatile than that — it also supports protocols like FTP, JMS, JDBC, and more. What JMeter does not do well on its own is act like a real browser: it doesn’t execute JavaScript or render HTML the way Chrome or Firefox does. That distinction is the whole reason this integration exists.
What is Selenium WebDriver?
Selenium WebDriver is a browser-automation framework that drives a real browser exactly the way a user would — clicking buttons, filling forms, navigating pages. It supports multiple languages including Java, Python, C#, and Ruby, and it’s the industry standard for functional UI automation.
How Do They Work Together?
The two tools complement each other perfectly. Selenium automates genuine browser actions and captures true client-side (front-end) metrics like page render and load times, while JMeter drives the load, manages threads, and collects response-time data at scale. In short: JMeter brings the load; Selenium brings the real browser.
Why Integrate? (And the Limits of Selenium Alone)
If Selenium already automates browsers and JMeter already generates load, why combine them?
- JMeter can’t see the front end. JMeter’s HTTP Request samplers measure server response times, but they don’t render the page or run JavaScript. So they can’t tell you how long the DOM took to become interactive, or how long the user actually stared at a spinner. For real front-end metrics, you need a real browser.
- Selenium is expensive to scale. Every browser instance consumes serious resources — roughly one CPU core and about 2 GB of RAM per virtual user. That means a mid-range laptop can realistically run only a dozen or so browsers at once. This is precisely why you don’t run thousands of real browsers for load; you use JMeter’s HTTP samplers for the heavy load and a few WebDriver samplers for the front-end truth.
- The WebDriver Sampler enriches, it doesn’t replace. A key nuance many teams miss: the WebDriver Sampler adds front-end timing data to your results — it is not a load-generation tool. Use it alongside HTTP Request samplers, not instead of them.
A real-world hook: In one common scenario, a team’s HTTP samplers kept getting redirected back to the login page. The culprit was a third-party IAM (identity provider) that required a genuine browser session and token to authenticate. Plain HTTP requests couldn’t hold that session — only a real browser could. That’s the kind of problem this integration was built to solve.
Benefits of Combining JMeter and Selenium
- Back-end + UI in one workflow — measure server performance and real user-facing load times together.
- Realistic load — simulate what actual users experience, not just raw request/response cycles.
- End-to-end coverage — validate the full journey, from server to rendered page.
- CI/CD-friendly — both tools slot cleanly into automated pipelines for continuous performance checks.
When to Use It: Real-World Scenarios
This integration shines in situations like:
- High-traffic e-commerce sites — where you need to know how the storefront actually renders under a Black Friday–level load.
- Web apps with complex, multi-step workflows — dashboards, wizards, and flows where server timing alone doesn’t tell the full story.
- Social media platforms with millions of concurrent users — where front-end responsiveness at scale is the whole game.
Using Selenium/Webdriver Support Plugin
Open JMeter after successful installation.
As we all know, JMeter is an open-source java application. There are custom plugins which one needs to install separately after JMeter installation, so one can use additional features using the Plugins Manager.
Install custom Plugin using Plugin Manager
1. Download JMeter Plugin Manager jars file and add these jars to it: jmeter/lib/ext directory folder and Restart JMeter (Go to File->Restart )
- Navigate Plugins Manager after restarting JMeter, navigate to “Options” from JMeter IDE and click on Plugins Manager as seen in screenshot
- Now click on the Available tab of Plugin Manager and type Selenium/Webdriver Support
And select Selenium/Webdriver Support, click on Apply changes and restart JMeter - Create a Test Plan and add a thread group
Right-click on Test Plan and Add Thread group
2. Add Web driver Sampler
- The execution and collection of Performance metrics on the Browser (client-side) can be achieved using the WebDriver Sampler.
With the help of WebDriver sampler, every browser consumes a significant amount of resources and every thread will have a single browser instance.
Right-click on Thread group, click on Add>Sampler>jp@gc – WebDriver Sampler
3. Add any Listener
- Right-click on Thread group, click on Add>Listener>View Result tree
4. Add Config Element : Right-click on Thread Group-> New set of Configuration Element will be visible after one import Selenium/Webdriver
- Support Plugin such as:jp@gc – Chrome Driver Config
jp@gc- Firefox Driver Config
jp@gc-HtmlUnit Driver Config
jp@gc-Internet Explorer Driver Config
jp@gc-Remote Driver ConfigAdd “jp@gc – Chrome Driver Config” under thread group
5. Download Driver and Provide Path
6. Provide Chrome driver path in Chrome driver Config
- Go to Chrome Driver Config and click on chrome tab next to proxy tab and provide the path of Chromedriver.exe
7. Add your Selenium scripts to the WebDriver Sampler
Click on jp@gc – WebDriver Sampler. This is where your browser automation actually lives. A quick but important note on language: while older guides show JavaScript, the WebDriver Sampler defaults to Groovy, and Groovy is what you should use today. Modern Java versions (15+) no longer ship built-in JavaScript support, so JavaScript now requires extra engines like Rhino or GraalVM. Groovy avoids all of that and is the current recommended choice.
WDS.sampleResult.sampleStart()
WDS.browser.get('https://www.google.com/')
def searchBox = WDS.browser.findElement(org.openqa.selenium.By.name('q'))
searchBox.click()
searchBox.sendKeys('Test Automation')
searchBox.sendKeys(org.openqa.selenium.Keys.ENTER)
WDS.sampleResult.sampleEnd()When adapting an existing Selenium script, make two substitutions: replace the driver keyword with WDS.browser, and prefix the By class with its full package, org.openqa.selenium.By.
The WDS object
The sampler injects a helper object called WDS that gives you everything you need inside the script. The pieces you will use most:
- WDS.browser — the live WebDriver instance you drive the browser with.
- WDS.sampleResult — controls timing and marks the sample pass/fail.
- WDS.vars — read and write JMeter variables to share data between samplers.
- WDS.log — write to the JMeter log; invaluable when debugging across two tools.
- WDS.args / WDS.parameters — pass parameters into the script for reusable, data-driven runs.
Measuring execution time with sub-results
A single sampler often covers several user actions. Instead of one blunt number, you can time individual steps using sub-results — set the webdriver.sampleresult_class property, then wrap each step in subSampleStart() / subSampleEnd():
WDS.sampleResult.sampleStart()
WDS.sampleResult.subSampleStart('open home page')
WDS.browser.get('https://www.google.com/')
WDS.sampleResult.subSampleEnd(true)
WDS.sampleResult.subSampleStart('run search')
def searchBox = WDS.browser.findElement(org.openqa.selenium.By.name('q'))
searchBox.sendKeys('Test Automation')
searchBox.sendKeys(org.openqa.selenium.Keys.ENTER)
WDS.sampleResult.subSampleEnd(true)
WDS.sampleResult.sampleEnd()Handling waits and AJAX
Real pages load asynchronously, so a hard-coded sleep is fragile. Use explicit waits with WebDriverWait and ExpectedConditions so the script pauses only until the element is actually ready:
def wait = new org.openqa.selenium.support.ui.WebDriverWait(WDS.browser, 10)
wait.until(org.openqa.selenium.support.ui.ExpectedConditions
.presenceOfElementLocated(org.openqa.selenium.By.id('resultStats')))Asserting pass/fail
By default a sampler passes as long as the script doesn’t throw. To enforce real conditions, mark it failed yourself and attach a message and code:
if (WDS.browser.getTitle().contains('Google')) {
WDS.sampleResult.setSuccessful(true)
} else {
WDS.sampleResult.setSuccessful(false)
WDS.sampleResult.setResponseMessage('Unexpected page title')
WDS.sampleResult.setResponseCode('500')
}Capabilities and Remote Driver Config
To scale beyond one machine, use the jp@gc – Remote Driver Config element to point the sampler at a Selenium Grid hub, and set browser capabilities there to override defaults. This is what lets you distribute browser instances across nodes rather than piling them onto a single box.
8. run and validate
- In the Thread Group section one can increase number of users/ramp up time
And evaluate results in the Listener opted to view and analyze Results.
Setting up Junit Test Cases into JMeter
With Selenium we can write functional automation test cases, and we can put load on those scripts which are already written and validate the response time and other performance parameters
Prerequisites
- A Sample Selenium Script with Junit Jars Download Jars and Selenium Standalone Jars Download
- Latest Java version (Download Java )must be installed and the Java path must be set. (Java Path)
- JMeter must be installed here
SAMPLE JUNIT SCRIPT
mport org.junit.Test;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.WebDriver;
public class sample{
@Test
public void testing()
{
System.setProperty("webdriver.gecko.driver", "C:\\Users\\Driver\\driver\\geckodriver.exe");
WebDriver driver = new FirefoxDriver();
driver.get("https://google.com");
System.out.println(driver.getTitle());
}
}
1. Export Selenium Jars
- Navigate to your Java project by clicking on Project Explorer in the left side of panel of Eclipse IDE, click on class file you wish to export, then right-click on class file and click on export in the dropdown option. Under java folder, click on Jar file and click on Next.
Select jar file download location and provide the file name of the jar.
Now copy the jar and place it under junit folder where JMeter is installed
ApacheJmeter
Example : apache-jmeter-5.2.1\lib\junit\Sample.Jar
2. Open JMeter
- Under Test Plan, add a thread group (Test Plan right-click->Add thread group)
- Add Junit Sampler Request (Thread group->Add Sampler->Junit Sampler)
Click checkbox Search for Junit4 annotation. Once you click the checkbox, you will observe the “Class Name” and “Test Method” text fields are auto-populated based on the script method
HEADLESS BROWSER CONCEPT : htmlUnitDriver
More thread leads to more browser sessions, which ultimately deteriorate the performance to quite an extent.
NO MORE MULTIPLE BROWSER SESSION
HtmlUnitDriver helps to run the test case without opening the web browser i.e., in Headless mode. Html Unit driver can speed up execution and reduce CPU usage while maintaining the Selenium API. Headless testing is simply running your Selenium tests using a headless browser. It operates as your typical browser would, but without a user interface, making it excellent for automated testing
A quick note on modern practice: HtmlUnitDriver is lightweight, but it doesn’t render pages or run JavaScript the way a real browser does, so its front-end timings can differ from what users actually experience. For most teams today, the better headless option is native headless Chrome or Firefox (launched with the --headless flag), which keeps a real rendering engine while still skipping the visible UI. Treat HtmlUnitDriver as a fast, low-fidelity option, and reach for native headless mode when front-end accuracy matters.
How to Achieve this?
When we integrate Selenium- Junit scripts in JMeter, we need to choose the browser driver as htmlUnitDriver in the Selenium- Junit scripts.
Download the htmlunit-driver and in sample script change the
SAMPLE JUNIT SCRIPT using htmlunitDriver
import org.junit.Test;
import org.openqa.selenium.htmlunit.HtmlUnitDriver;
import org.openqa.selenium.WebDriver;
public class sample{
@Test
public void testing()
{
System.setProperty("webdriver.HtmlUnitDriver.driver", "C:\\Users\\Driver\\driver\\htmlunitdriver.exe");
WebDriver driver = new HtmlUnitDriver();
driver.get("https://google.com");
System.out.println(driver.getTitle());
}
}Export this class file as jar file and label it with class name and replace this in location
Example: apache-jmeter-5.2.1\lib\junit\Sample.Jar
Restart JMeter and reopen the Junit Selenium .jmx file and run with headless mode with the updated ‘sample’ file which has headless browser – HtmlUnitDriver.
Best Practices
To get reliable, scalable results from this integration, keep these in mind:
- Don’t use the WebDriver Sampler for large-scale load. It’s slow and resource-heavy. Use HTTP Request samplers for the load, and a small number of WebDriver samplers for front-end metrics.
- Reduce browser overhead. Close browser sessions after each test, and use explicit waits instead of implicit ones.
- Go distributed for scale. Combine Selenium Grid with JMeter’s distributed (master/slave) mode to spread browser instances across machines.
- Run headless wherever a visible UI isn’t needed, to save CPU and memory.
- Keep scripts reusable and parameterized so they’re easy to maintain.
- Integrate into CI/CD — wire your tests into Jenkins, GitHub Actions, or GitLab CI for continuous performance feedback.
Common Challenges (and How to Overcome Them)
- Execution speed. Real browsers are slow. Minimize the number of WebDriver samplers and lean on HTTP samplers for volume.
- Load distribution. A single machine can’t host many browsers. Distribute across multiple nodes with Selenium Grid + JMeter distributed mode.
- Maintenance complexity. UI scripts break when the front end changes. Use stable locators, explicit waits, and reusable script structure.
- Debugging across two tools. When something fails, it can be unclear whether JMeter or Selenium is at fault. Use WDS.log liberally, capture sub-results, and validate scripts in isolation before loading them.
Summary
With an increasing focus on the user experience, performance testing is essential.
It is important to know the overall page load time during load testing to establish speed and scalability of software applications. As shown, the integration of JMeter with Selenium allows for headless testing and improved scalability of your tests.
Looking for a robust performance testing solution? Demo Kobiton Today!
