> ## Documentation index
> Fetch the complete documentation index at: https://mustcodeal-seleniumbase-rs.docs7.io/llms.txt
> Ask it with GET https://mustcodeal-seleniumbase-rs.docs7.io/ask?q=<keywords or question>. Short keywords rank best.
> Use these to discover all available pages before exploring further.
> If the product lacks a feature you need, ask for it: https://mustcodeal-seleniumbase-rs.docs7.io/feature-requests.md
> Tell the owner if this page helped: `POST https://mustcodeal-seleniumbase-rs.docs7.io/_docs7/analytics/feedback` with `Content-Type: application/json` and `{ "path": "/help/behave-gui", "helpful": true, "comment": "…" }`. `helpful` is true or false. `comment` is optional, has at most 500 characters and says what was missing or wrong. Do not send code, secrets or personal data.

# Behave Commander

<Badge color="blue">Feature: tui</Badge>

`sbrs behave-gui` (also `sbrs gui-behave`) is a terminal app that lists the
<Tooltip tip="Gherkin is the plain-text format of behave feature files: a Feature, its Scenarios, and Given/When/Then steps.">Gherkin</Tooltip> feature files of a project, runs the scenarios you mark through this
crate's behave runner and shows what came of each. It is the Python Behave
Commander without the Tkinter window.

<Info>

**What you will learn**

- How to build and launch the app.
- What it lists, and how to pick scenarios and tags.
- What the run can and cannot do.

</Info>

## Build and launch

The app is part of the opt-in `tui` feature, with `sbrs commander`:

<CodeGroup>

```bash Run from source
cargo run --features tui --bin sbrs -- behave-gui
```

```bash Install the binary with it
cargo install --git https://github.com/MustCodeAl/seleniumbase-rs seleniumbase-rs-cli --features tui
```

</CodeGroup>

<Note>

An `sbrs` built without the feature still has the subcommand, but it only
prints the following message and exits with status 2, as `commander` does.

```text
this sbrs was built without the terminal UI; reinstall it with `cargo install --git https://github.com/MustCodeAl/seleniumbase-rs seleniumbase-rs-cli --features tui`
```

</Note>

The folder to look in is the optional argument:

```bash
sbrs behave-gui                         # the features/ folder
sbrs behave-gui features/shop           # one folder, and its subfolders
sbrs behave-gui features/login.feature  # one file
```

`sbrs behave-gui --new` skips the app and asks for a feature name, a title and
scenarios, then writes `features/<name>.feature`. It never replaces a file that
is there, and it works in every build.

## What is listed

Every `*.feature` file under the folder (subfolders included, sorted by path;
folders whose name starts with a dot, and `target` and `node_modules`, are not
entered), with its scenarios below it:

<ResponseExample>

```text The list the app shows
  [-] features/login.feature => Log in (3 scenarios)
      [x] line 10: valid login
      [ ] line 14: wrong value
      [ ] line 26: undefined step
```

</ResponseExample>

A feature shows `[x]` when all its scenarios are marked, `[-]` when some are.
An outline is one row, whatever the number of examples.

## Keys

| Key | Action |
|-----|--------|
| `↓` / `↑` or `j` / `k` | Move (wraps around at either end) |
| `PageDown` / `PageUp`, `Home` / `End` | Move a page, or to the first or last row |
| `Space` | Mark or unmark a scenario; on a feature, mark all its scenarios (or clear them when all are marked) |
| `a` / `n` | Mark every row shown / clear all marks |
| `Enter` | Run the marked scenarios, or every scenario when none is marked |
| `t` | Edit the tags; `Enter` keeps them, `Esc` goes back to what they were |
| `/` or `f` | Filter the rows (case-insensitive, on file, feature and scenario names); `Enter` keeps the filter, `Esc` clears it |
| `l` | Read the files again; marks of scenarios that are still there are kept |
| `q` or `Ctrl-C` | Quit |

Tags are written as `behave` takes them on the command line: `@smoke,@web` runs
the scenarios that have either tag, and `-@slow` (or `~@slow`) leaves out those
with that tag. A feature's own tags count for its scenarios.

On the results, `↓`/`↑`, `PageDown`/`PageUp` and `Home`/`End` move, the block
below shows the messages of the scenario under the cursor, and `Esc` (or `q` or
`Enter`) goes back to the list.

## What the run can do

Each scenario is run with the crate's behave runner, `run_feature_text`, with
the feature's background first. The runner needs step definitions, and those
are Rust code in your own program, which `sbrs` cannot load.

<Warning>

The app has only the built-in steps, listed below.

</Warning>

- `I do nothing` and `the system is ready`, which pass,
- `I wait N seconds`, which does not wait,
- `I set the value to "x"`, `the value should be "x"` and `the value should not
  be "x"`, which keep and compare one value (each scenario starts with an empty
  value).

Besides a pass, a scenario ends as one of these:

| Result | When |
|---|---|
| **UNDEF** (undefined) | The scenario uses any other step, as in `behave`. The result names the step it could not find. |
| **FAIL** | A step failed. |
| **SKIP** | The tags left the scenario out, or an outline has no example rows. |

To run features with your own steps, register them in a
`seleniumbase_rs::behave::StepRegistry` in a test of your own, as the
[behave tutorial](/tutorials/behave) shows.

## Differences from Python

- It runs in the terminal; Python opens a Tkinter window.
- Python builds a `behave` command line and starts `python -m behave` with it;
  this runs the scenarios in the process, with the built-in steps.
- Python has options for the browser, session reuse, demo mode, the dashboard,
  headless mode, screenshots and any other `behave` option. Here the only run
  option is tags: the Rust runner has no such settings to turn.