Executing Custom JavaScript in the Browser Console During Codeless Execution

Introduction:

Some web applications need a small piece of JavaScript to run in the browser console before the application is ready to be tested — for example, to initialise session context or to seed a UI widget with sample data without walking through a full login flow. Because that command is normally typed by hand in DevTools, it cannot be captured by standard Codeless actions such as click, type, or select, and the test case stops being fully automated.

This help document explains how to replicate that manual console command inside a TestGrid Codeless test case using a Custom Expression (Java) step, so the script fires automatically as part of the test flow. It walks you through adding the step in the right position, writing a script that waits for the page’s JavaScript functions to become available, validating the result, and troubleshooting the errors you are most likely to hit. The examples below use a generic sample application with placeholder function names and values, so you can adapt the same pattern to your own application.

Why a UI step is not enough:

Applications of this kind initialise session context (for example, an operator ID and a signed session token) and pre-populate widget inputs (for example, an account reference and a verification flag) through global JavaScript functions on the page. These functions exist purely for setup purposes and have no corresponding UI element, so there is nothing for a codeless recorder to capture. Driving them directly with JavaScript is the only reliable way to reproduce the manual step.

Step 1: Open the test case in the Codeless Test Case Writer.

Log in to the TestGrid portal with valid credentials and open the test case you want to automate in the Codeless Test Case Writer.

Step 2: Keep the “Launch URL” step first.

Leave the existing Launch URL step as the first step in the flow. The custom script needs a loaded page to run against, so the application must be launched before it executes.

Step 3: Add a Custom Expression (Java) step.

Add a new step immediately after Launch URL and select Custom Expression (Java) as the step type.

Step 4: Paste and adapt the custom script.

Paste the script shown below into the step, substituting your application’s actual function names and argument values for the placeholders. The script uses JavascriptExecutor to call the page’s global functions and WebDriverWait to make sure each function exists before it is called.

Step 5: Save the step in the correct position.

Save the step. It must execute after the page loads and before any UI interaction steps, exactly where the manual console command used to sit.

Step 6: Run the build.

Run the build. The script now fires automatically as part of the test flow, replacing the manual console step, and the test case runs unattended.

Sample custom script:

The script below is a generic template. Replace initSession, populateWidgetInputs, and the placeholder arguments with the function names and values used by your application.

JavascriptExecutor js = (JavascriptExecutor) driver;

// Step 1: Wait until the session-init function is available, then call it
new WebDriverWait(driver, Duration.ofSeconds(20)).until(
    (WebDriver d) -> Boolean.TRUE.equals(
        ((JavascriptExecutor) d).executeScript(
            "return typeof initSession === 'function';")
    )
);

js.executeScript(
    "initSession(10001, " +
    "'demo-token-9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c');"
);

// Step 2: Wait until the widget-input function is available, then call it
new WebDriverWait(driver, Duration.ofSeconds(20)).until(
    (WebDriver d) -> Boolean.TRUE.equals(
        ((JavascriptExecutor) d).executeScript(
            "return typeof populateWidgetInputs === 'function';")
    )
);

js.executeScript(
    "populateWidgetInputs('sample_widget', JSON.stringify(" +
    "{accountId:'ACC-100200300', isVerified:true}));"
);

Equivalent manual console session:

For reference, the manual console session this step replaces typically looks like the sample below. The values are placeholders for illustration only and are not captured from a live system.

> initSession(10001, "demo-token-9f8e7d6c5b4a3f2e1d0c9b8a7f6e5d4c");
> populateWidgetInputs("sample_widget", JSON.stringify({
    accountId: "ACC-100200300",
    isVerified: true
  }));

< [DEBUG] session initialized for operatorId: 10001
< [INFO] widget 'sample_widget' inputs set: {"accountId":"ACC-100200300","isVerified":true}

Expected result:

• Session initialised: The console log confirms the session was initialised, usually with a debug or info message referencing the operator or session ID that was passed in.
• Widget state pre-populated: The application loads with the expected account and widget state already in place.
• Flow continues unattended: Subsequent Codeless steps execute normally, with no manual intervention at any point in the run.

Troubleshooting:

• “function is not defined” or similar reference errors: The page’s JavaScript bundle had not finished loading when the script ran. Increase the WebDriverWait timeout, or add a wait for a stable page element before the custom script step.
• Widget inputs not reflected in the UI: Confirm that the function name and the JSON payload keys and casing exactly match what your application expects.
• Token or ID expires between runs: Retrieve these values dynamically — for example through an API call step or a TestGrid global variable — instead of hardcoding them, so the same test case stays valid across builds and environments.

Conclusion:

Moving a manual browser-console command into a Custom Expression (Java) step removes the last manual touchpoint from a Codeless test case. By waiting for the page’s global functions and then invoking them through JavascriptExecutor, you get the same setup the console gave you, reproduced identically on every build. Follow the steps outlined in this guide to make session-dependent test cases run fully unattended in TestGrid.

Integrating Selenium Custom Scripts with Codeless Automation