Execution Modes

Branko Juric edited this page Sep 19, 2017 · 38 revisions

Gwen logo Execution Modes

Execution modes include:

Features and feature suites

Gwen can execute single feature files and suites of feature files in a directory. Any number of files or directories can be passed to Gwen in a single call. Tags can also be passed to include and exclude features and scenarios annotated with those tags.

  • Executing a single feature file
    • When a single feature file is passed to Gwen, only that file is executed.
  • Executing suites of features files
    • When a directory is passed to Gwen, all feature files in the directory and its subdirectories are executed.

Implicit meta discovery

For any given feature file, any existing meta files in the feature file's path are discovered and loaded first before it is executed. This makes all the bindings and @StepDefs defined in the meta available to that feature.

Explicit meta loading

If your meta is located in a directory that is external to your features, you can load it explicitly using the -m or --meta launch option.

Interactive REPL execution

By default, Gwen will run in interactive mode which means it will start the REPL console as soon as it finishes executing features. This allows you to interactively enter commands to analyse the state of the environment or to continue entering additional steps. This is useful for testing the execution of features and verifying additional steps you want to add.

Batch execution

If you specify the --batch option when launching Gwen, it will immediately exit after it finishes executing features. This is useful for when you want to run Gwen in a server environment and/or when you do not want to have an interactive REPL session open after the execution completes.

See also: What are the batch and REPL modes?

Serial execution

If you launch Gwen with a list of features or a directory (suite of features), the it will by default execute each feature file one at a time in sequential or discovered order respectively.

Parallel execution

To execute features in parallel, simply specify the --parallel option when launching Gwen. All features passed to Gwen will then execute in parallel, one on each core.

For example, if you launch Gwen on a quad core machine with the --parallel option passing in four feature files (or a single directory containing 4 feature files), then the four features will run in parallel across the four cores. If you instead provide five features, then four of them will execute in parallel and the remaining one will wait until one of them completes and then run on that available core.

Dry run execution and validation

Dry runs can be performed on features to verify that they are syntactically correct and that all bindings and references hang together and will resolve. This allows you to quickly validate features and catch potential errors before executing them. It runs fast and is especially useful for refactoring. The -n or --dry-run option is used to launch Gwen in this mode.

For example, to validate all features in the features directory:

gwen features -n
gwen features --dry-run

Data driven execution

CSV data files can be passed into the interpreter to perform feature execution over multiple data sets. If a data file exists in a feature file's directory (or somewhere in it's path) it will be automatically discovered and used to execute the feature over each of its data records. Only one such CSV file is allowed in any feature path (a runtime error will be thrown if more than one anywhere in the path is found). The first row in a CSV data file must be a list of column names for the contained data that follows. The values in each record will be bound to attributes in the feature scope having these same names. Feature steps can reference the bound data using these names.

CSV data feeds

Say you have a users.csv file containing following user records.

my first name,my last name,my job
Gwen,Stefani,Pop Singer
Gwen,Cooper,Torchwood Agent

The first row in this file specifies a comma separated list of column names. The remaining rows specify the comma separated lists of values for each record. Now say you wanted to submit the details for each user to a web page through a single submit-user.feature file that accepts all the user data as input one at a time. You can do this in the feature by referencing CSV data values by their column names as follows:

 Feature: Submit user

Scenario: submit user details
    Given I navigate to the user details page
     When I type my first name in the first name field
      And I type my last name in the last name field
      And I type my job in the job field
      And I click the save button
     Then the alert msg should be "User ${my first name} saved"

The current CSV record number (starting at 1) is available as an implicit attribute named data record number and can be accessed by reference or interpolation.

You can now execute this feature for all users in the CSV file by issuing the following Gwen command. Gwen will auto discover the CSV file if it is in the same directory or somewhere in the path of the feature file.

gwen submit-user.feature

If you want to be explicit, you can specify the location of the CSV file through the -i or --input-data option. Some examples follow:

  • gwen -i users.csv submit-user.feature
  • gwen --input-data users.csv submit-user.feature
  • gwen -i /some/other/path/users.csv submit-user.feature

Gwen will read in the CSV file, and for each record will:

  • Bind the data to the feature
  • And execute the feature

If you specify the -r <report-dir> option, a feature detail report will be generated for each data record. If you specify the --parallel option, the feature will execute all records in parallel.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.