skip to content

What does the selenium-side-runner command line let you do with a .side project that Selenium IDE cannot?

level: middleimportance: nice to knowfreq 34%

answer

  1. No browser extension involved at all
  2. Installed from npm, runs on Node
  3. The exit status is the verdict
  4. One flag moves the whole recording environment
  5. Capabilities and a remote endpoint are flags

basics

~20 s

It runs a recorded .side project without the browser extension, from a script or pipeline, choosing the browser and target environment by flag, running tests in parallel or on a remote Grid, and exiting non-zero when one fails.

solid answer

~40 s

`selenium-side-runner` is the Node command-line executor for `.side` files, installed with `npm install -g selenium-side-runner`. Because it reads the JSON project directly and needs no extension, a recording becomes something a pipeline can gate on: the process exit status is the verdict, and `--output-directory` writes results to collect. Its flags cover what a recording cannot express by itself - `-c` chooses the browser capabilities, `-s` sends the session to a remote WebDriver endpoint such as a Grid you run, `--base-url` overrides the base URL stored in the project so a recording made against production replays against staging, `-w` sets how many tests run at once, `-f` filters by test name, and `--params` passes values through. It executes exactly the IDE command set, no more.

code

bash · 2 lines
bash
npm install -g selenium-side-runner
selenium-side-runner -c "browserName=chrome" -w 4 --base-url https://staging.reports.example.com --output-directory results solar-yield-report.side

go deeper

for a junior

Be ready to say that a .side project can be run from a command line as well as from the extension, and that this is what lets a recording run in a pipeline at all.

for a middle

Explain what the main flags do - capabilities, remote server, base URL override, worker count, name filter - and why the base URL override works without editing any recorded step.

for a senior

Show the judgment about what the runner does and does not change: it moves a recording somewhere useful but improves neither its locators nor its missing assertions, and parallelism exposes the state a recording assumed.

for a principal

Be able to weigh a low-code runner in a delivery pipeline against a maintained code suite, including who owns the recordings, who is on the hook when they break, and what the command-set ceiling costs over time.

## What `selenium-side-runner` is `selenium-side-runner` is the **command-line executor** for the `.side` project files that Selenium IDE writes. It is published on npm and installed with `npm install -g selenium-side-runner`, and it runs on Node.js. The important property is that it needs **no browser extension**: it reads the JSON project directly, drives a real browser through WebDriver, and exits with a non-zero status when a test fails. That single property is what turns a recording from something one person replays on their laptop into something a pipeline can gate a deployment on. You point it at one or more files, or a directory, or a glob: ```bash selenium-side-runner solar-yield-report.side selenium-side-runner ./recordings/*.side ``` ## The flags that carry the work | Flag | What it does | |---|---| | `-c`, `--capabilities` | the WebDriver capabilities for the session, for example `-c "browserName=firefox"` | | `-s`, `--server` | the URL of a remote WebDriver endpoint, so the run happens somewhere other than this machine | | `--base-url` | overrides the base `url` saved inside the project | | `-w`, `--max-workers` | how many tests run at once | | `-f`, `--filter` | run only the tests whose names match | | `--output-directory` | write machine-readable result files for the pipeline to collect | | `--params` | general parameters handed through to the run | `--base-url` is the one that repays itself first. A recording is made against whatever host you had open; the yield report was recorded against production data at `https://reports.example.com`, and the same rows can be replayed against `https://staging.reports.example.com` with a flag rather than a re-record. Because `open` targets are stored as relative paths against the project's base URL, the whole recording moves environment with that one override. ## Running somewhere other than this laptop `-s` hands the run to a remote WebDriver endpoint - a Selenium Grid you operate, most usefully - instead of starting a browser locally, and `-c` chooses which browser the session asks for. Together they mean one recorded `.side` project can be replayed across the browsers a Grid advertises without editing a single row, because nothing in a recorded step is browser-specific: `command`, `target` and `value` describe intent, and the driver decides how to carry it out. ## Parallelism and what it demands of the recording `-w` sets how many workers run concurrently. The recording itself has to be worth parallelising, and a recorded flow usually is not until you have dealt with two things: - **Shared data.** Two workers replaying the same yield-report recording against the same north array will collide if the flow mutates anything. - **Starting state.** A recorded flow that assumes you are already signed in, or already on a particular report, fails in a fresh worker session that starts cold. The project's `suites` array also carries its own `parallel`, `persistSession` and `timeout` members, set in the IDE, which describe how the tests it groups are meant to run. ## Results, and the difference from pressing Play `--output-directory` writes results the pipeline can pick up and publish, and the process exit status is what actually gates the build. Contrast the two ways of running the same file: 1. **Selenium IDE.** Interactive: you watch each row highlight, you can pause, step, edit a `target` and replay a single command. Unbeatable while you are still building the recording. 2. **`selenium-side-runner`.** Non-interactive: no editing, no stepping, no visual feedback - but scriptable, headless-capable, parallel, remote-capable and repeatable, and it produces a pass or fail somebody else can act on. ## What the runner still does not give you - It **executes the IDE command set** and nothing more. Anything that needs logic beyond `if`/`while`/`times`/`forEach` and `executeScript` has no home in a `.side` file. - It does not improve the recorded locators. A step anchored to a positional XPath is exactly as fragile at the command line as it was in the extension. - It does not add assertions. A project with no `assert*` rows runs green under the runner for the same reason it runs green in the IDE. - It is a separate installation from the extension, and a pipeline agent needs Node.js, a browser and the matching driver present, or a Grid to send the session to. The runner answers the question "how do I run this recording somewhere useful". Whether the recording is worth running is still the earlier question, and the answer to it lives in the rows themselves.

  • Why does `--base-url` move a whole recording between environments with one flag?
    Because a `.side` project stores its host once, as the top-level `url`, and every `open` step holds a relative path resolved against it. Overriding that one value redirects every navigation in the project. A recording that hard-coded absolute URLs in each `open` step would need every row edited instead.
  • What has to be true of a recorded project before `-w` actually helps?
    Its tests have to be independent. Two workers replaying flows that touch the same yield-report data collide, and a recorded flow that assumes you are already signed in or already on a report fails in a fresh worker that starts cold. Parallelism exposes the shared state and starting-state assumptions a recording quietly inherited from the session it was made in.
  • What can the runner not do that pressing Play in the extension can?
    Everything interactive: highlighting each row as it runs, pausing mid-flow, stepping one command at a time, editing a target and replaying just that step. The extension is the drafting environment, the runner is the execution environment, and neither replaces the other.

saying these in an interview costs you the question

  • Thinks the extension must be installed for the runner to work
  • Believes a project must be exported to code before it can run headless
  • Assumes the runner rewrites recorded locators into better ones
  • Edits every open step by hand to change environment
  • Expects the runner to add assertions a recording never had