Gherkin test cases

A case writes its steps in one of two formats. Classic steps are an action, optional data, and an expected result. Gherkin steps are a keyword and its text, with an optional Doc String or Data Table as the argument, and no expected result. Choose Gherkin when your team describes behavior as scenarios, or when those scenarios already live in .feature files.

Question	Answer
Which keywords can a step use?	`Given`, `When`, `Then`, `And`, `But`, or `*` (neutral, for a step that names no role).
Where is the format chosen?	In the case editor, with the Classic / Gherkin switch. The project’s default applies to new cases.
Does a Gherkin step have an expected result?	No. Put the outcome in a `Then` step.
Can a Gherkin case use shared steps?	Only Gherkin shared steps. A shared step’s format is fixed when it is created.
How are results recorded?	Per step, as with classic steps: Passed, Failed, Skipped, or Blocked.

Choose a case’s format

Use the Classic / Gherkin switch at the top of the steps in the case editor: on the new case page, in the detail panel, and in the expanded dialog. Switching converts the steps in place:

Switch from	What happens
Classic to Gherkin	Each step keeps its text and takes the keyword `*`. Expected results are dropped; Probara asks first and tells you how many.
Gherkin to Classic	Each step’s action becomes its keyword and text, such as `Then the badge shows 1`. The argument becomes the step’s data.

While the case uses shared steps, its format cannot change. Convert or remove them first.

Write Gherkin steps

The Rows view is the default: one row per step, with a keyword, the step text, and an optional argument. The argument is a Doc String (text between two """ lines) or a Data Table (rows that start with |).

The Raw view edits every step as text. It is available for Gherkin cases only, and it is disabled while the case uses shared steps. While it is open, add steps by writing new lines; the step buttons come back in Rows. Each step is one line: a keyword, then its text. A Doc String goes between """ lines, and a Data Table starts with | on the lines right after its step:

Given these users exist
| name | role   |
| Ana  | admin  |
| Ben  | member |
When Ana signs in
Then the dashboard opens

Probara marks each line it cannot read, such as a line without a keyword, a step without text, or a Doc String that is not closed. It does not save until you fix those lines.

Parameters

A Gherkin case reads both ${name} and <name> placeholders in its title, description, steps, Doc Strings, and Data Tables. A Scenario Outline’s Examples are the case’s parameters, so a <name> in a step matches an Examples column. See Parameterized test cases.

Project default format

In project settings, the Repository tab has Default step format, set to Classic or Gherkin. A new case takes it unless its author picks another format. Changing the default leaves existing cases as they are.

Shared steps

A shared step has one format. You choose it in the create dialog with Step format, and it cannot change afterwards. A Gherkin case can use only Gherkin shared steps: the insert picker lists only the sets of the case’s format, and the API refuses a mismatch with 422. Create shared step from selection gives the new set the case’s format. See Shared steps.

Runs and history

In the execution panel, a Gherkin step shows its keyword before its text, and its argument under Argument instead of Data. It has no expected result. Past attempts show the same layout. A run keeps the keywords it was created with, like the rest of a step’s content, until you apply the latest version of the case.

An outline’s Examples create one run case for each combination, and each run case records its own results.

The version comparison shows changes to a step’s keyword and to the case’s step format.

Import and export `.feature` files

Import

Choose Gherkin (.feature) as the source in the import dialog. The file must carry the .feature extension and contain one Feature. Probara reads English keywords only. A file that lives in a repository is better kept in sync, so its cases follow the file: see Syncing feature files from Git.

In the file	In Probara
`Feature:`	A suite at the top of the import. The Feature’s description is not imported.
`Rule:`	A suite nested inside the Feature’s suite.
`Scenario:`	One Gherkin case.
`Scenario Outline:` with `Examples:`	One Gherkin case. Its Examples become the case’s parameters: one column becomes a single parameter, and two or more columns become one group named `Examples`. Each row is one combination of the case.
`Background:`	The case’s preconditions, as Gherkin lines.
A `# Preconditions:` comment above a scenario	Added to the case’s preconditions.
Tags	Probara tags. Tags on a Feature or a Rule apply to every scenario under it.
Steps, Doc Strings, and Data Tables	Gherkin steps with their keyword and argument.

A file fails as a whole, and the error names the line, when a line cannot be placed. Three cases do this: a second Feature: line, an Examples: block that does not follow a Scenario Outline, and a # language: line for a language other than English.

An Examples table that the parameter rules cannot hold, such as a single column with more than 100 rows, does not fail the file. The case imports without its parameters, and the import shows the warning “Parameters not applied — case imported without them”.

Export

Choose Gherkin (.feature, zip) in the export dialog. The download is a zip with one .feature file per suite, and it holds Gherkin cases only. A selection with no Gherkin case is refused.

A case with parameters exports as a Scenario Outline with one Examples table: a column for each parameter name, and a row for each combination the case runs. A .feature export writes the combinations the case runs as one Examples table; excluded combinations and the single/group split are not kept. Importing the file again therefore gives the case one group named Examples, or one single parameter when the table has one column.

Each scenario starts with a comment holding its case ID, such as # SHOP-12. Probara does not read that comment back: to update the cases a file came from, import it with Replace matching test cases on, which matches each scenario to the case with the same title in the target suite. The Git sync does not read the comment either: bind a scenario to its case with a @probara:SHOP-12 tag. Replace matching skips the cases synced from Git, so importing an export does not change them.

Synced from Git

A case synced from a .feature file in a repository shows the Synced from Git badge, with the file’s path and line. Its title, description, steps, precondition and the tags its file gives it are read-only: change the scenario in the file, through a pull request. Its steps cannot be converted into a shared step, and its step format cannot change. Assignee, priority, custom fields, defects, comments, plans and runs stay editable. See Syncing feature files from Git.

The Examples of a synced outline are its parameters. A change to them in the file changes the case through the sync. A scenario whose Examples the parameter rules cannot hold is refused as a whole, and the sync names the scenario and its line.

Limits

Attachments are not imported, the same as with every other format.
Parameters follow the same limits as every other format: for example, 20 parameter names per case and 1,024 combinations per case. See Parameterized test cases.

API and MCP

The API accepts stepFormat when a case is created or updated, keyword on each step, and defaultStepFormat on a project. It also accepts parameters and excludedCombinations on a case. A save that changes the scenario of a synced case answers 409 test_case_synced_read_only. See the API reference and the MCP tool reference.