Its been a long time and I am back after a very tight work schedule.

Earlier I have written an article about dealing with scenarios which involve both UI as well as API testing using Selenium and SoapUI.

Since that time, Rest Assured has been evolved as a most commonly used API Test Automation Framework and also it goes well with Java.

Last week I came across a Selenium Conference talk where I got to know about an interesting library called Selenium to Rest Assured Adapter.

This will simplify some of our automation tests, which needs automation at both UI and API levels.

In my previous posts, Selenium Webdriver – Get SessionID from a Web Application and SoapUI Get SessionID we have explored how to extract a session information from Selenium and passing it into our API Automated tests using SoapUI.

Now we are gonna explore the same using Rest Assured using the Selenium-To-RestAssured library.

For this, we need to download the latest jar file from Download Selenium-To-RestAssured Jar file and you have to add it to your classpath in your IDE – Eclipse or IntelliJ Idea.

If you are using Maven to manage the dependencies in your project, you can add the following to your pom.xml


In selenium, to get a cookie from AUT, we use,

driver.manage().getCookieNamed("COOKIE NAME");

To use the cookie in rest assured tests, simply we have to create an instance for the CookieAdapter class and using the convertToRestAssured method like below. Then we can use the cookie in our RestAssured API Tests.

org.openqa.selenium.Cookie cookieToConvert = driver.manage().getCookieNamed("COOKIE NAME");
CookieAdapter cookieAdapter = new CookieAdapter();
io.restassured.http.Cookie adaptedCookie = cookieAdapter.convertToRestAssured(seleniumCookie);


The above snippet is extremely useful if we are automating API testing with an application that has a complex login process. We can log into the application via the browser using selenium, grab the necessary logged in Cookies from the browser, close the browser down, and then use the Cookies in our API Tests.

This Selenium-To-RestAssured is a dual way adapter and it converts cookie from RestAssured into a selenium cookie as well.

This can be used when you made an HTTP login request and you have to extract the response Cookie and store them in the browser.

Once we have the converted cookie we can add them to our browser like below.

io.restassured.http.Cookie cookieToConvert = response.getDetailedCookie("COOKIE NAME")
CookieAdapter cookieAdapter = new CookieAdapter();
org.openqa.selenium.Cookie convertedCookie = cookieAdapter.convertToSelenium(cookieToConvert);
driver.navigate().refresh(); // We refresh the page so it reads the newly added cookies

This library is an open source and you can dig deeper into the source code here – Selenium-To-RestAssured-Github

Thanks to Mark Winteringham for this innovative creation.


Headless CHROME With Selenium Web Driver

Till Google Chrome 59, headless execution has been achieved using third party tools like PhantomJS or HTMLUnitDriver.

Earlier if you want to achieve headless test execution in Chrome, you had to use Xvfb (short for X virtual framebuffer). This is an in-memory display server for Linux which enables you to run graphical applications without a display.

But Google has released updates to chrome to achieve an inbuilt Headless test execution without using Xvfb or any other third party tools using a real browser – Chrome. This is available on Mac and Linux Os from Chrome 59. If you are using Windows, you need up update your Chrome version to 60 or above to achieve headless execution.

How to do Headless Test Execution: Its simple. All you have to do is add a chrome options argument before initializing your driver.

ChromeOptions options = new ChromeOptions();
WebDriver driver = new ChromeDriver(options);

Selenium 3.0 Officially Out Now

Yes. This is one of the major and stable release in the recent times since 2.0 got released around 5 years back.

What’s new we can expect: For users who are using WebDriver API’s this is gonna be just a drop in effortless replacement. But those who are using Selenium Grid may have to go through some minimal configuration changes.

In this version, they have removed the original Selenium Core implementation and replaced it with one backed by WebDriver. For people who are still using Selenium RC should have to undergo some maintenance because of this. This is the right time to migrate the code to WebDriver API’s.

Right from Selenium 3.0, all the major browser vendors are responsible for shipping their own implementation of WebDrivers for their browsers.

Starting with Safari-10, Apple started providing native support for WebDriver API’s. More details here – WebDriver Support in Safari 10

Google already started providing support for WebDriver API’s for Google Chrome using their ChromeDriver.

Even Microsoft when they came up with a new browser “EDGE” for Windows-10, they also came out with support for the WebDriver API’s – Microsoft WebDriver

Mozilla is doing major changes in the internals of Firefox browser to make it more stable and secure. So if you are using Firefox for your testing, you’ll need to use the GeckoDriver, which is an executable similar to the ChromeDriver. But Gecko is still in Alpha and you may have to face lot of issues with your automation w.r.t. Firefox.

The W3C specification for browser automation, based on Open Source WebDriver is still In-Progress and this is gonna reach “recommendation” status.

What you are waiting for? Just go and download the latest from Seleniumhq Downloads

Jmeter Groovy Scripting – Call External Scripts

In my previous post, Jmeter BeanShell Scripting – Call External Scripts we have discussed how to user Jmeter Bean Shell script to call external .bsh scripts.

Now in this post, we are going to see how to do the same functionality with JSR 223 sampler + Groovy scripting.

It’s always recommended to use JSR 223 Sampler instead of Bean shell Sampler. I recently got a nice comparison between these two in this post – BeanShell Vs JSR223 Sampler

The JSR223 test elements have a compilation feature that can significantly increase performance.

To get benefit from this feature, Use external .groovy Script files instead of in lining them. This will make Jmeter compile them if this feature is available on Script Engine and cache them.

To get additional benefits from Caching and compilation, language engine used for scripting must implement JSR223 compilable interface.

Groovy is one of the JSR223 compilable interface. But Java, Bean Shell and Java script are not.

Since JMeter 2.8, JSR223 Test Elements using external Script file are now pre compiled and this enables great performance enhancements.

So we are going to use JSR223 test elements with external Groovy script files.

Pre Requisites:

Groovy isn’t shipped with Jmeter. So it needs to be downloaded separately.  To get started:

  1. Download latest groovy binary bundle from
  2. Copy all the Jar files under “groovy-{versionNumber}\lib” and paste it into “Jmeter/lib/ext” folder of your Jmeter installation directory.
  3. Restart Jmeter.


Now we are going to do the same scenario as in the previous post. But instead of http requests, I am gonna do FTP Requests. In short following is the scenario.

I have to do upload some flat files to a FTP server through FTP requests and the flat files are available on a sub directory where my test plan file – .JMX file exists. So I have to parse the list of available files and have to pass the file names as input to my FTP Requests.

I am going to create two external groovy script files for this scenario.

One is for listing out the files under sub directory and putting the absolute path of the Flat files it into a Jmeter variable.

Another script is for extracting the file names alone from the absolute path Jmeter variables.

Following is the “FlatFilePathProcessor.groovy” script file content and I have saved this file where our test plan file exists.


String subDirectory = args[0];
String testPlanFile = FileServer.getFileServer().getBaseDir().replace('\\', '/');
//String testPlanFileDir = FilenameUtils.getFullPathNoEndSeparator(testPlanFile).replace('\\', '/');

vars.put("testPlanFileDir", testPlanFile);

File folder = new File(testPlanFile + "/" + subDirectory + "/");
File[] listOfFiles = folder.listFiles();
int counter = 1;
for (File file : listOfFiles) {
if (file.isFile()) {
vars.put(subDirectory + "_" + counter, testPlanFile + "/" + subDirectory + "/" + file.getName());
vars.put("FileNames" + "_" + counter, file.getName());

Following is the “ExtractFileName.groovy” script file content and I have also saved this file where our test plan file exists.

String fullPath = vars.get("FlatFiles");
int index = fullPath.lastIndexOf("/");
String fileName = fullPath.substring(index + 1);
vars.put("FileName", fileName);

Following is the project structure that we are going to create.


Create a test plan and then create a thread group below that.

First we are going to add JSR 223 sampler in our thread group. – the job of this sampler is to call the FlatFilePathProcessor.groovy file with sub directory name as a parameter. So the request will list out the flat files under sub directory and putting the absolute path of each and every flat file it into a Jmeter variable. Following is the request.


Next we are going to create a ForEach Controller, which will loop through the FTP for each flat file variable created in the above step. Following is our controller.


Now we are going to create JSR 223 Pre-processor. The job of this test element is to call ExtractFileName.groovy to extract the file name from the absolute path. Because for FTP request we need both the file name as well as the absolute file path.

Also one more thing I have noticed is, in FlatFilePathProcessor.groovy itself, we have created two variables one contains the absolute path and another for the file name. But now we are under the ForEach controller, which will process/loop through only one variable. I have not seen any reference where the ForEach controller loop through multiple variables. Following is the request.


Here comes the actual FTP Request, with simple response code assertion. We have used two variables here – one for filename that we got from preprocessor [ExtractFileName.groovy] and another for the absolute file path of the flat file which we are going to upload, that we got from sampler [ExtractFileName.groovy].


Add debug sampler and your favorite listener to see this in action.

The source code of the sample program is here –

Jmeter BeanShell Scripting – Call External Scripts

Recently I come across a requirement to use Beanshell Scripting in Jmeter. So following is my requirement.

  1. Create 2 thread groups for 2 Http Requests to make API Calls and in that http request, my Post body should be iterated for around 9000 flat files in two different directories. Following is the Project Structure I have.1
  1. For HttpRequest1 under ThreadGroup1 I have to iterate for all the text files in ‘DirectoryOne’
  2. For HttpRequest2 under ThreadGroup2 I have to iterate for all the text files in ‘DirectoryTwo’


  1. Need to use absolute Path for pointing to the directory where my files exist – Not a better solution, when running from the CI build, this absolute path will vary.
  2. Need to use another CSV file(s) to configure the list of filenames available under ‘DirectoryOne’ and ‘DirectoryTwo’ – Not a feasible solution. If there is any new addition of new files under any directory, I have to update my CSV file to include the new file names as well.
  3. Read the text file content and pass it as a post body request.

Let’s start solving this issue.

I started exploring the bean shell sampler in Jmeter. I have created a bean shell script to process the flat files under ‘DirectoryOne’. Following is the bean shell script

import org.apache.jmeter.gui.GuiPackage;


String testPlanFile = GuiPackage.getInstance().getTestPlanFile();

String testPlanFileDir = FilenameUtils.getFullPathNoEndSeparator(testPlanFile).replace('\\', '/');

vars.put("testPlanFileDir", testPlanFileDir);

File folder = new File(testPlanFileDir + "/" + "DirectoryOne" + "/");

File[] listOfFiles = folder.listFiles();

int counter = 1;

for (File file : listOfFiles) {

if (file.isFile()) {

vars.put("DirectoryOne" + "_" + counter, testPlanFileDir + "/" + "DirectoryOne" + "/" + file.getName());





If you look into the above issue, I have pointed to the root directory [whatever it may be] where my test plan file exist and then I am appending my sub directory name to it.

But for ThreadGroup2, I have to copy paste the same bean shell sampler with same script except for ‘DirectoryTwo’ instead of ‘DirectoryOne’. So I thought of reusing the same bean shell script for all the thread groups. The only option is to externalize it.

Now I have created a file called “FilePathProcessor.bsh” inside the same directory where my test plan file exists. One interesting thing that I have noticed in the bean shell sampler was it will even run the external .bsh scripts with arguments passed from Jmeter.

Again I have to use a relative path to locate this external .bsh file. Following is the small snippet that you can use to point your bean shell Sampler – “Script File Text Box”.

${__BeanShell(import; FileServer.getFileServer().getBaseDir();)}${__BeanShell(File.separator,)}FilePathProcessor.bsh

This means, no need for providing the absolute path to locate the external bean shell script. The above code will point to the base directory where our test plan/.JMX file exists.

Now we have to pass the sub directory names as an argument in the “Parameters (-> String Parameters and String []bsh.args)” text box.

For first ThreadGroup, I have passed it as ‘DirectoryOne’.

For Second ThreadGroup, I have passed it as ‘DirectoryTwo’.

So my updated external bean shell script will look like,

import org.apache.jmeter.gui.GuiPackage;


String subDirectory = bsh.args[0];

String testPlanFile = GuiPackage.getInstance().getTestPlanFile();

String testPlanFileDir = FilenameUtils.getFullPathNoEndSeparator(testPlanFile).replace('\\', '/');

vars.put("testPlanFileDir", testPlanFileDir);

File folder = new File(testPlanFileDir + "/" + subDirectory + "/");

File[] listOfFiles = folder.listFiles();

int counter = 1;

for (File file : listOfFiles) {

if (file.isFile()) {

vars.put(subDirectory + "_" + counter, testPlanFileDir + "/" + subDirectory + "/" + file.getName());





So my final project structure will look like,


FilePathProcessor – the Bean Shell Sampler. This will produce JmeterVariables for each file located in the sub directory. For example, when iterating over the files in ‘DirectoryOne’ and if it has two files exists, this will produce two Jmeter Variables with Prefix ‘DirecotryOne’. You can see this in action using Jmeter Debug Sampler.

DirectoryOne_1 = “D:\DirectoryOne\Test1.txt”

DirectoryOne_2 = “D:\DirectoryOne\Test2.txt”.

I have created ‘ForeEach Controller’ to parse these Jmeter Variables.


The “Output Variable Name” in the ‘ForEach Controller’ will contain the absolute path of the text files. Now to parse the text inside a text file, we can simply use in-built Jmeter functions. Go-to Body Data of HttpRequest and write ${__FileToString(${DirectoryOneFileNames})}

The _FileToString in built Jmeter function will return the file content of a given flat file.


So that’s it. Now we have solved all the possible challenges in-front of us. If you want to have complete information about this project, you can simply have a look at this sample script here.

Virtualization using Vagrant for Selenium Tests

Say goodbye to “works on my machine” bugs.

Nobody likes to release software on a Friday. What if something breaks over the weekend? There’s nothing like debugging an issue in production when you’re doing some day drinking at a BBQ.

But you have nothing to worry about, right? I mean, you tested the application and it worked on *your* machine. Too bad that’s never good enough. Have fun working this weekend.

If only you had automated tests for your application (across all of the browsers and all the platforms you cared about). Then you could rest easy this weekend and enjoy the festivities.

Creating a robust and scalable execution environment for automation tests is a very essential phase. In automated tests for web, we actually need to cover different browsers and platforms.

In this documentation, we are going to see how to run our selenium tests in a Linux box using vagrant.

Basically I have a selenium test that works fine when running in different browsers in my Windows host machine. But I want to make sure that it is running fine on the browsers in a Linux box too. Instead of creating an actual VM and running my tests, I am simply going to create a light weight portable Linux box and I am going to run my selenium tests from my windows host machine.

Also every time that you want to run your tests in your local machine, it opens the browser on top of the other windows, preventing you from doing something else. Unless you use Phantomjs or HTMLUnitDriver, it is not possible to run Chrome or Firefox hidden, without disturbing you on your work. Now using Vagrant and VirtualBox, you only need to start the VM, and all your tests will be run into the VM. You can continue developing in the meanwhile!


Vagrant provides us easy to configure, reproducible, and portable work environments. Vagrant stands on top of VirtualBox, VMware and some other service providers. If you’re a developer, Vagrant will isolate dependencies and their configuration within a single disposable, consistent environment. If you’re a tester, Vagrant will help you to create light weight Virtual environments to run your tests against all the possible OS + Browser combinations.


  1. Download and install Oracle VM Virtualbox –
  2. Download and install Vagrant –

From command line, type vagrant –v and make sure that you get the version number that you installed. Vagrant 1.7.21

Vagrant Boxes:

Boxes are the package format for Vagrant environments. A box can be used by anyone on any platform that Vagrant supports to bring up an identical working environment. The easiest way to use a box is to add a box from the publicly available catalog of Vagrant boxes for VirtualBox. We can also add and share our own customized boxes on this website.

I am going to use this box chef/ubuntu-14.04 – a standard Ubuntu 14.04 x64 base install.

Getting Started:

  1. Create a workspace directory to store the vagrant configuration file and shell scripts.

I have created “D:\Automation\Vagrant\Demo”

  1. From Command line go to your workspace and type vagrant init chef/ubuntu-14.04


  1. Make sure that the vagrant file is created in “D:\Automation\Vagrant\Demo”
  2. Run the command vagrant up

3If you are running this for first time, it may take some considerable amount of time to download the virtual box image and will put it under C:\Users\<username> \VirtualBox VMs\Demo_default_*

  1. Now the Ubuntu base image VM is up and running. Run the Command vagrant halt. This will power off the VM. Because we need to provision this VM with selenium related libraries, browsers and some utilities to run our selenium tests.
  2. Update the vagrant file in “D:\Automation\Vagrant\Demo” with the following content. Basically the default generated vagrant file has some lot of optional behaviors which are commented by default and you may enable it you need. But we require only the following content in a vagrant file.


Vagrant.configure(2) do |config| = "chef/ubuntu-14.04"
   config.vm.provision :shell, :path =&gt; "" :forwarded_port, guest:4444, host:4444

Basically what we are trying to do above is enabling port forwarding in the VM. Selenium server will use the 4444 port by default and we are forwarding that port from VM to host machine.

Also we are going to provision this VM using the “” shell script. Provisioners in Vagrant allow you to automatically install software, alter configurations, and more on the machine, as part of the vagrant up process. This is useful since boxes typically aren’t built perfectly for your use case. Of course, if you want to just use vagrant ssh and install the software by hand, that works. But by using the provisioning systems built-in to Vagrant, it automates the process so that it is repeatable. Most importantly, it requires no human interaction, so you can vagrant destroy and vagrant up and have a fully ready-to-go work environment with a single command.

Vagrant gives you multiple options for provisioning the machine, from simple shell scripts to more complex, industry-standard configuration management systems. If you’ve never used a configuration management system before, it is recommended you start with basic shell scripts for provisioning.

So to run a selenium test in a new plain OS, we need following things.

  • JDK/JRE – To run the selenium server.
  • Google chrome browser
  • ChromeDriver
  • Some utilities like ‘Unzip’ to extract the chromedriver zip file.
  • Selenium Standalone Server
  • Xvfbor X virtual framebuffer – To run tests in headless mode.

Xvfb is a display server implementing the X11 display server protocol. In contrast to other display servers, Xvfb performs all graphical operations in memory without showing any screen output. So actually when we run our tests in a VM box, we won’t be able to see any browser popping up. It means no GUI interactions are possible. So I am going to install all the above packages along with the dependencies using

  1. Create in the “D:\Automation\Vagrant\Demo” with the following content.

#!/usr/bin/env bash

# Set start time so we know how long the bootstrap takes

T="$(date +%s)"

#echo 'Updating'

sudo apt-get -y update

echo 'Installing Zip/Unzip'

sudo apt-get -y install zip unzip

echo 'Installing Google Chrome'

sudo apt-get -y install google-chrome-stable


sudo dpkg -i google-chrome-stable_current_amd64.deb

sudo apt-get -y install -f

echo 'Installing Google XVFB'

sudo apt-get -y install xvfb

sudo apt-get -y install -f

echo 'Installing JRE'

sudo apt-get -y install default-jdk

sudo apt-get -y install -f

echo 'Downloading and Moving the ChromeDriver/Selenium Server to /usr/local/bin'

cd /tmp

wget ""

wget ""


mv chromedriver /usr/local/bin

mv selenium-server-standalone-2.35.0.jar /usr/local/bin

export DISPLAY=:10

cd /vagrant

echo "Starting Xvfb ..."

Xvfb :10 -screen 0 1366x768x24 -ac &

echo "Starting Google Chrome ..."

google-chrome --remote-debugging-port=9222 &

echo "Starting Selenium ..."

cd /usr/local/bin

java -jar selenium-server-standalone-2.35.0.jar

# Print how long the bootstrap script took to run

T="$(($(date +%s)-T))"

echo "Time bootstrap took: ${T} seconds"

  1. Run vagrant up –provision this will start the VM and then install the list of packages that we have added in the sh and also it will start the selenium server in 4444 port.


You can see this by navigating to http://localhost:4444/wd/hub/static/resource/hub.html from your windows host machine [As we have port forwarded].

Now run the following selenium test from any of your favorite IDE.

package test;

import java.util.concurrent.TimeUnit;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;

public class HeadlessSession {	  
	  public static void main(String args[]) throws InterruptedException, Exception {	  
	  public static void HeadlessSessionId() throws Exception {
               DesiredCapabilities capabilities = new DesiredCapabilities();
	       WebDriver driver = new RemoteWebDriver(new URL("http://localhost:4444/wd/hub"), capabilities);	  
		  try {				
			    String baseUrl = "";
			    driver.manage().timeouts().implicitlyWait(60, TimeUnit.SECONDS);
			    System.out.println("Title : " + driver.getTitle());
			    String browserName = capabilities.getBrowserName().toLowerCase();
			    System.out.println("Browser : " + browserName);
		  } catch (Exception e) {
		  finally {

That’s it. Now you have successfully ran your tests in Chrome browser in a Linux box from your windows host machine.

Useful Vagrant Commands:

Command Action
vagrant up Power on the VM
vagrant halt Power off the VM
vagrant reload Restart
vagrant suspend Saving the VM state and sleep
vagrant resume Resuming the suspended VM
vagrant provision Provision the VM by running the or any other shell script mentioned in the vagrant file.
vagrant up –provision Power on with provision
vagrant reload –provision Restart with provision


  1. Easy to setup and maintain.
  2. It’s free.
  3. Able to clone the production/staging environment for our test execution.
  4. Light weight and portable.
  5. Support to provisioning scripts like Shell, Chef, and Puppet.
  6. Simple command line based workflow.
  7. Goodbye to ‘Works on my machine’ bugs.
  8. For selenium, you can able to run headless tests on your favorite browser.
  9. Create and destroy the VMs as needed.
  10. It works on all major platforms.
  11. We can also use Selenium Grid along with vagrant to run tests parallely across different VM’s.


  1. Base boxes for your choice of operating system might not be readily available.
  2. Little bit of time consuming to make vagrant VM up and running.
  3. Taking lot of time when provisioning the VM box. To avoid this, create your own base box by installing all the required dependencies by manually SSH into it and then use provisioning script only for starting the Selenium Server.
  4. Light weight. But looks fatty when considering the alternatives like Docker.
  5. It requires you to have a hard drive file that can be huge and it takes a lot of RAM.

Using Context in Soap-UI/Ready API External Script Library

In the recent post we have seen how to use the external script library to perform a session id extraction from an application.

One interesting thing I recently come across is, we can also use soap-UI context in our external script library.

Context is a built-in variable automatically made available by soapUI.

You can able to define/add your own properties of context objects
For those who are familiar with writing groovy test steps in Soap-UI definitely should heard of this term before.

//An example to set property and get property using soap-UI context.
context.setProperty("URL", "")"URL"))

Lets see how this is going to be useful in our tests.

Let’s consider the same script that I have used before in my previous post
In that, have a look at the code written in “The Script Library to get the SessionID

The method session contains three parameters. URL, Username and Password.

If you are going to call this session method from inside your Soap-UI, you will need to pass the value for these three parameters.

Obviously, Things like URL, Username and Password will be usually stored in a Project Level Property to make it easy for configuration.

So you have to first get these three Project Level Property and then you have to call this external script library.

So if you have a close look at the section “How do we Call this Script inside our SoapUI test cases?” in this Post,

You can able to see that we have extracted the project level property in a variable and then we have used these variables as a parameter in when calling the session method.

def groovyUtils = new context );
String url = context.expand( '${#Project#AuthenticateRequestURL}' )
String username = "yourusername";
String password = "yourpassword";
Obj = new Headlessdriver();
String session = Obj.session(url, username, password);

Do we really need to do this every time when we call the external script library? Answer is NO.

We can still use the ‘context’ variable in our external script library also. So I have updated the Headlessdriver.groovy as follows.

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver; 
import org.openqa.selenium.WebElement;
import java.util.concurrent.TimeUnit;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.phantomjs.PhantomJSDriver;
import org.openqa.selenium.phantomjs.PhantomJSDriverService;

class Headlessdriver {

	String url;
	String username;
	String password;
	String phantomPath;

	def Headlessdriver( context ) {        
        this.url = context.expand( '${#Project#URL}' );
		this.username = context.expand( '${#Project#username}' );
		this.password = context.expand( '${#Project#password}' );
		this.phantomPath = context.expand( '${#Project#phantomPath}' );

	String session () {

		DesiredCapabilities caps = new DesiredCapabilities();
		// caps.setCapability("phantomjs.binary.path", "ext\\phantomjs.exe");
		caps.setCapability("phantomjs.binary.path", phantomPath);
		String[] args = [ "--ignore-ssl-errors=yes" ];
		caps.setCapability(PhantomJSDriverService.PHANTOMJS_CLI_ARGS, args);
		WebDriver driver = new PhantomJSDriver(caps);
		driver.manage().timeouts().implicitlyWait(60L, TimeUnit.SECONDS);
		String sessionIdFull = driver.manage().getCookieNamed("sessionId").toString();
		String SessionId = sessionIdFull.split("; ")[0];
		return SessionId;

Now you don’t need to extract the project level property in your groovy script test step before calling this external script library.
Calling this Headlessdriver.session() method is simple as below.

Obj = new Headlessdriver( context );
String session = Obj.session();