Selenium UI Load Guide

Use this guide when Selenium browser journeys should run inside the same LoadStrike transaction and reporting model.

What this page helps you do

What this page helps you do

Use this guide when Selenium browser journeys should run inside the same LoadStrike transaction and reporting model.

Who this is for

Teams deciding how a protocol or browser runtime should fit inside one transaction-aware scenario.

Prerequisites

  • A transport or browser flow that already matters to the workload

By the end

A clearer protocol-specific path that still fits the same scenario and reporting model.

Use this page when

Use this page when Selenium UI Load Guide belongs inside the transaction story and you need the supported path into the same scenario model.

Visual guide

Decision diagram showing plain HTTP steps, tracked endpoints, and browser flows.
Choose the protocol path that matches where the transaction starts and which part of the system proves completion.

Guide

What this guide is for

Use this guide when Selenium WebDriver is already part of the team workflow and you want to run those browser flows under LoadStrike instead of maintaining a separate load harness.

Where driver lifecycle belongs

Create the driver in WithInit when one scenario copy should reuse the same browser session, or create it inside the step when each iteration needs a fresh browser. Always close it in WithClean or finally.

How to think about load

Like Playwright, Selenium browser sessions are heavier than protocol-only requests. Increase copies gradually and watch host capacity closely.

How to map UI outcomes

Turn successful browser flows into LoadStrikeResponse.Ok and map assertion, lookup, or timeout failures into LoadStrikeResponse.Fail with status codes the rest of the team can interpret quickly.

Protocol setup samples

Use these samples to wire Selenium UI Load Guide into the same scenario and reporting model as the rest of your workload.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

Selenium UI Step

using LoadStrike;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;

var scenario = LoadStrikeScenario.Create("ui-login", async context =>
{
    var step = await LoadStrikeStep.Run<string>("login", context, () =>
    {
        var options = new ChromeOptions();
        options.AddArgument("--headless=new");

        using var driver = new ChromeDriver(options);
        driver.Navigate().GoToUrl("https://example.com/login");
        driver.FindElement(By.Id("email")).SendKeys("[email protected]");
        driver.FindElement(By.CssSelector("button[type='submit']")).Click();

        return Task.FromResult(LoadStrikeResponse.Ok<string>(statusCode: "200"));
    });

    return step.AsReply();
})
.WithLoadSimulations(LoadStrikeSimulation.KeepConstant(2, TimeSpan.FromSeconds(20)));

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Selenium workflow choices

Driver creation

Create the driver in WithInit for reuse or inside the step when each iteration must own its own browser lifecycle.

Driver cleanup

Always stop the browser in WithClean or finally so stale browser processes do not accumulate.

LoadStrikeStep

Use a named step so browser flow latency and failures appear in normal reports and thresholds.

Outcome mapping

Return LoadStrikeResponse.Ok or Fail with status codes the rest of the team can recognize quickly.