Write Gauge specifications¶

Specs directory¶

When a Gauge project is created and initialized, a specs directory is automatically created at <project_root> with a sample file, example.spec. This sample file helps you understand how to write a specification.

Example

The following is an example of a Gauge specification:

# Search specification
Tags: search, admin

The admin user must be able to search for available products on the search page

## Successful search
Tags: successful

For an existing product name, the search result will contain the product name

* User must be logged in as "admin"
* Open the product search page
* Search for product "Cup Cakes"
* "Cup Cakes" should show up in the search results


## Unsuccessfull search

On an unknown product name search the search results will be empty

* User must be logged in as "admin"
* Open the product search page
* Search for product "unknown"
* The search results will be empty

For more information about Markdown, see Markdown Syntax.

Specification heading¶

A specification must begin with a specification heading. A specification must contain only one specification heading.

Specification heading is written in the <H1> Markdown syntax in one of the following ways:

# Spec Heading

or

Spec Heading
============

Example

In the following example, # Search specification is the specification heading, followed by tags and steps (statements preceded by *).

# Search specification
Tags: search, admin

The admin user must be able to search for available products on the search page

* User must be logged in as "admin"
* Open the product search page

Scenario¶

Each scenario represents a single workflow in a particular specification. A specification must contain at least one scenario.

A scenario starts after a scenario heading or a scenario name. The scenario heading is written in Markdown <H2> syntax in one of the following ways:

## Scenario heading

or

Scenario heading
----------------

A scenario contains one or more steps in it. A scenario can be tagged by using tags.

Example

In the following example, the specification, Search specification contains the scenario, ## Successful search. This scenario heading is followed by tags and steps.

# Search specification

The admin user must be able to search for available products on the search page

## Successful search
Tags: successful

For an existing product name, the search result will contain the product name

* Search for product "Cup Cakes"
* "Cup Cakes" should show up in the search results

# Search specification

## Vowel counts in multiple word

 |Word  |Vowel Count|
 |------|-----------|
 |Gauge |3          |
 |Mingle|2          |
 |Snap  |1          |
 |GoCD  |1          |
 |Rhythm|0          |

This is the second scenario in this specification

Here's a step that takes a table

* The word <Word> has <Vowel Count> vowels.

Step¶

Steps are the executable components of a specification that are written by using the Markdown unordered list syntax. In a specification, steps can exist either within a scenario or outside a scenario. When steps are used outside a scenario, they can be of the following types:

• Context steps

• Tear Down steps.

Steps also exist inside a Concept.

Every step implementation has an equivalent code as per the language plugin used while installing Gauge. This code is run when the steps inside a spec are executed.

Example

In the following example, the two sentences preceded by asterisk, *, are the unordered steps listed inside the Successful search scenario.

# Search specification

## Successful search
Tags: successful

For an existing product name, the search result will contain the product name

* Search for product "Cup Cakes"
* "Cup Cakes" should show up in the search results

The values written in quotes, ", are parameters that are passed into the equivalent code of the step implementation for that particular language plugin.

Parameters¶

Steps are defined to take values as parameters so that they can be reused with different parameter values.

The equivalent code of the step implementation for that particular language plugin must also have the same number of parameters as mentioned in the step.

Examples

In the following example, parameter values are "Cup Cakes" (within double quotes) within the two steps.

## Successful search
Tags: successful

For an existing product name, the search result will contain the product name

* Search for product "Cup Cakes"
* "Cup Cakes" should show up in the search results

In the following example, parameter values are "product 1" and "product 2".

* Check "product 1" exists
* Check "product 2" exists

A step can have the following types of parameters:

• Simple parameters

• Dynamic parameters

• Table parameters

• Special parameters

* Search for product "Cup Cakes"
* Create a "gauge-java" project
* Write "100" line specification

# Create projects

    |id| name      |
    |--|-----------|
    |1 | Alice     |
    |2 | Bob       |
    |3 | Eve       |

## First scenario
* Say "hello" to <name>.

## Second scenario
* Say "namaste" to <name>.

# Login as user <username> and create project <project_name>

* Login as user <username> and "password"
* Navigate to project page
* Create a project <project_name>

# Login specification

## Successful login scenario

* Login as user "john" and create project "Gauge java"

# Create projects

## First scenario

* Create the following projects
     |project name| username |
     |------------|----------|
     | Gauge java | Daredevil|
     | Gauge ruby | Iron Fist|

# Create projects

    |id| name |
    |--|------|
    |1 | john |
    |2 | mike |

## First scenario

* Create the following projects
    |project name| username |
    |------------|----------|
    | Gauge java | <name>   |
    | Gauge ruby | <name>   |

* Verify email text is <file:email.txt>

* Check if <file:/work/content.txt> is visible

* Step that takes a table <table:data.csv>

* Check if the following users exist <table:/Users/john/work/users.csv>

Id,Name
1,The Way to Go On
2,Ivo Jay Balbaert

Tags¶

Tags are used to associate labels with specifications or scenarios. Tags help in searching or filtering specs or scenarios.

Tags are written as comma separated values in the specification with a prefix Tags: . Both scenarios and specifications can be separately tagged, however, only one set of tags can be added to a single specification or scenario. A tag applied to a spec automatically applies to a scenario as well.

When the number of tags used is more, tags can be defined in multiple lines to enhance readability.

Example: Single line tag

In the following example, both the specification, Search specification, and scenario, Successful search, have tags. search and admin tags, which are used for the specification also apply to the scenario. Additionally, the scenario has its own set of tag, which is successful.

# Search specification
  Tags: search, admin

## Successful search
   Tags: successful

Example: Multi-line tag

In the following example, both the specification and scenario have tags in multiple lines. Tags have to be indented when written in multiple lines.

# Login specification

Tags: login,
 admin, user-abc

## Successful login scenario

Tags: admin,
 login-success

How to add comments in a specification¶

Any sentence in plain text which does not follow any syntax is seen as a comment in a spec. Comments help enhance readability of a spec without being executed.

Example

In the following example, The admin user must be able to search for available products on the search page is a comment. This is in plain text without any syntax and provides information about the specification. Similarly, For an existing product name, the search result will contain the product name is also a comment within the scenario and provides information about the scenario. These comments enhance readability without getting executed when the specification is run.

# Search specification
Tags: search, admin

The admin user must be able to search for available products on the search page

## Successful search
Tags: successful

For an existing product name, the search result will contain the product name

* User must be logged in as "admin"
* Open the product search page
* Search for product "Cup Cakes"
* "Cup Cakes" should show up in the search results

Concepts¶

Concepts provide the ability to combine re-usable, logical groups of steps into a single unit. A concept presents the summary of a business intent by combining logical groups of steps.

Concepts follow the same rules or guidelines that are required while using steps within a spec. Multiple concepts can be used within a spec and concepts can be nested too. When the specification is run, all concepts and their steps are executed in the defined order.

# Login as user <username> and create project <project_name>

# Login as user <username> and create project <project_name>

* Login as user <username> and "password"
* Navigate to project page
* Create a project <project_name>

# Login specification

## Successful login scenario

* Login as user "john" and create project "Gauge java"

Contexts¶

Contexts or Context steps are steps defined in a spec prior to a scenario. These steps allow you to specify a set of conditions that are necessary for executing scenarios in a spec. If there are multiple scenarios, context steps are executed prior to every scenario in the specification. A context step must be preceded by * and are executed in the defined order. Hence, they are similar to steps used in a scenario or concept.

Example

In the following example, the context steps are User is logged in as Mike and Navigate to the project page. These steps are defined and executed prior to the two scenarios, ## Delete single project and ## Delete multiple projects.

When the specification is run, the workflow is as follows:

1. Context steps execution

2. Delete single project scenario execution

3. Context steps execution

4. Delete multiple projects scenario execution

# Delete project

These are context steps

* User is logged in as "mike"
* Navigate to the project page

## Delete single project

* Delete the "example" project
* Ensure "example" project has been deleted

## Delete multiple projects

* Delete all the projects in the list
* Ensure project list is empty

Tear Down Steps¶

Tear Down Steps are defined in a spec after the last scenario. These steps allow you to specify some sort of a conclusion after every execution of a scenario in a spec. They are used to perform a tear down function.

If there are multiple scenarios, tear down steps are executed after every scenario in the specification. A tear down step must be preceded by * and are executed in the defined order. Hence, they are similar to steps used in a scenario or concept.

Three or more consecutive underscores, ___, indicates the start of tear down steps.

___
* Tear down step 1
* Tear down step 2
* Tear down step 3

Example

In the following example, the tear down steps that start after the three or more consecutive underscores, ___, are Logout user "mike" and Delete user "mike".

When the specification is run, the workflow is as follows:

1. Context steps execution

2. Delete single project scenario execution

3. Tear down steps execution

4. Context steps execution

5. Delete multiple projects scenario execution

6. Tear down steps execution

# Delete project

* Sign up for user "mike"
* Log in as "mike"

## Delete single project

* Delete the "example" project
* Ensure "example" project has been deleted

## Delete multiple projects

* Delete all the projects in the list
* Ensure project list is empty

____________________
These are teardown steps

* Logout user "mike"
* Delete user "mike"

Step implementations¶

Every step implementation has an equivalent code as per the language plugin used while installing Gauge. The code is run when the steps inside a spec are executed. The code must have the same number of parameters as mentioned in the step.

Steps can be implemented in different ways such as simple step, step with table, step alias, and enum data type used as step parameters.

* Say "hello" to "gauge"

// The Method can be written in **any C# class** as long as it is part of the project.
public class StepImplementation {

    [Step("Say <greeting> to <product name>")]
    public void HelloWorld(string greeting, string name) {
        // Step implementation
    }
}

// This Method can be written in any java class as long as it is in classpath.

public class StepImplementation {

    @Step("Say <greeting> to <product name>")
    public void helloWorld(String greeting, String name) {
        // Step implementation
    }
}

step("Say <greeting> to <name>", function(greeting, name) {
    throw 'Unimplemented Step';
});

// Asynchronous step implementation
step("Say <greeting> to <name>", async function(greeting, name) {
    // Async code
    throw 'Unimplemented Step';
});

step("Say <greeting> to <name>", function(greeting, name, done) {
    try {
        setTimeout(function () {
            // Code for step
            done();
        }, 1000);
    } catch(e) {
        done(e);
    }
});

// Handling errors in promises with done
step("Say <greeting> to <name>", function(greeting, name, done) {
    // Let promise1 be some promise we need to wait for.
    promise1
        .then(done)
        .catch(function(e) { done(e);});
});

@step("Say <greeting> to <product name>")
def hello_world(greeting, name):
    assert False, "Add implementation code"

step 'Say <greeting> to <product name>' do |greeting, name|
    # Code for the step
end

* Create following "hobbit" characters
  |id |name   |
  |---|-------|
  |123|frodo  |
  |456|bilbo  |
  |789|samwise|

* Create following "hobbit" characters <table:hobbits.csv>

// Here Table is a custom data structure defined by gauge.
// This is available by adding a reference to the Gauge.CSharp.Lib.
// Refer : http://nuget.org/packages/Gauge.CSharp.Lib/

public class StepImplementation {

    [Step("Create following <race> characters <table>")]
    public void CreateCharacters(string race, Table table) {
        // Step implementation
    }

}

// Table is a custom data structure defined by gauge.
public class StepImplementation {

    @Step("Create following <race> characters <table>")
    public void createCharacters(String race, Table table) {
        // Step implementation
    }

}

step("Create following <race> characters <table>", async function(race, table) {
    table.entries(function (entry) {
        console.log(`ID ${entry["id"]}`);
        console.log(`Name ${entry["name"]}`);
    });
});

# Here Table is a custom data structure defined by gauge.

@step("Create following <race> characters <table>")
def create_characters(race, table):
    assert False, "Add implementation code"

# Here table is a custom data structure defined by gauge-ruby.

step 'Create following <race> characters <table>' do |race, table|
    puts table.rows
    puts table.columns
end

# User Creation

## Multiple Users

* Create a user "user 1"
* Verify "user 1" has access to dashboard
* Create another user "user 2"
* Verify "user 2" has access to dashboard

public class Users {

    [Step("Create a user <user_name>", "Create another user <user_name>")]
    public void CreateUser(string user_name) {
        // create user user_name
    }

}

public class Users {

    @Step({"Create a user <user_name>", "Create another user <user_name>"})
    public void createUser(String user_name) {
        // create user user_name
    }

}

step(["Create a user <username>", "Create another user <username>"], function (username) {
    // do cool stuff
});

from getgauge.python import step

@step(["Create a user <user name>", "Create another user <user name>"])
def create_user(user_name):
    print("create {}.".format(user_name))

step 'Create a user <user name>','Create another user <user name>' do |user_name|
    // create user user_name
end

## User Creation

* User creates a new account
* A "welcome" email is sent to the user

## Shopping Cart

* User checks out the shopping cart
* Payment is successfully received
* An email confirming the "order" is sent

public class Users {

    [Step({"A <email_type> email is sent to the user",
    "An email confirming the <email_type> is sent"})]
    public void SendEmail(string email_type) {
        // Send email of email_type
    }

}

public class Users {

    @Step({"A <email_type> email is sent to the user",
    "An email confirming the <email_type> is sent"})
    public void sendEmail(String email_type) {
        // Send email of email_type
    }

}

step(["A <email_type> email is sent to the user",
"An email confirming the <email_type> is sent"],
function (email_type) {
    // do cool stuff
});

from getgauge.python import step

@step(["A <email_type> email is sent to the user",
"An email confirming the <email_type> is sent"])
def email(email_type):
    print("create {}.".format(email_type))

step 'A <email_type> email is sent to the user',
'An email confirming the <email_type> is sent' do |email_type|
    email_service.send email_type
end

Implementation¶

public class ExecutionHooks
{

    [BeforeSuite]
    public void BeforeSuite() {
        // Code for before suite
    }

    [AfterSuite]
    public void AfterSuite() {
        // Code for after suite
    }

    [BeforeSpec]
    public void BeforeSpec() {
        // Code for before spec
    }

    [AfterSpec]
    public void AfterSpec() {
        // Code for after spec
    }

    [BeforeScenario]
    public void BeforeScenario() {
        // Code for before scenario
    }

    [AfterScenario]
    public void AfterScenario() {
        // Code for after scenario
    }

    [BeforeStep]
    public void BeforeStep() {
        // Code for before step
    }

    [AfterStep]
    public void AfterStep() {
        // Code for after step
    }

}

public class ExecutionHooks {

    @BeforeSuite
    public void BeforeSuite() {
        // Code for before suite
    }

    @AfterSuite
    public void AfterSuite() {
        // Code for after suite
    }

    @BeforeSpec
    public void BeforeSpec() {
        // Code for before spec
    }

    @AfterSpec
    public void AfterSpec() {
        // Code for after spec
    }

    @BeforeScenario
    public void BeforeScenario() {
        // Code for before scenario
    }

    @AfterScenario
    public void AfterScenario() {
        // Code for after scenario
    }

    @BeforeStep
    public void BeforeStep() {
        // Code for before step
    }

    @AfterStep
    public void AfterStep() {
        // Code for after step
    }

}

beforeSuite(fn, [opts]) {
    // Code for before suite
}

beforeSpec(fn, [opts]) {
    // Code for before spec
}

beforeScenario(fn, [opts]) {
    // Code for before scenario
}

beforeStep(fn, [opts]) {
    // Code for before step
}

afterSuite(fn, [opts]) {
    // Code for after suite
}

afterSpec(fn, [opts]) {
    // Code for after spec
}

afterScenario(fn, [opts]) {
    // Code for after scenario
}

afterStep(fn, [opts]) {
    // Code for after step
}

Handling asynchronous code in hooks

// using done
beforeStep(function (context, done) {
    setTimeout(function() {
        done();
    }, 1000);
});

// using async functions
beforeStep(async function () {
    // async code for before step
});

from getgauge.python import before_step, after_step, before_scenario, after_scenario, before_spec, after_spec, before_suite, after_suite

@before_step
def before_step_hook():
    print("before step hook")

@after_step
def after_step_hook():
    print("after step hook")

@before_scenario
def before_scenario_hook():
    print("before scenario hook")

@after_scenario
def after_scenario_hook():
    print("after scenario hook")

@before_spec
def before_spec_hook():
    print("before spec hook")

@after_spec
def after_spec_hook():
    print("after spec hook")

@before_suite
def before_suite_hook():
    print("before suite hook")

@after_suite
def after_suite_hook():
    print("after suite hook")

before_suite do
    # Code for before suite
end

after_suite do
    # Code for after suite
end

before_spec do
    # Code for before spec
end

after_spec do
    # Code for after spec
end

before_scenario do
    # Code for before scenario
end

after_scenario do
    # Code for after scenario
end

before_step do
    # Code for before step
end

after_step do
    # Code for after step
end

Current Execution Context in the Hook¶

To get additional information about the current specification and scenario and step execution, an additional parameter called ExecutionContext can be added to the hooks method.

using Gauge.CSharp.Lib;
using static Gauge.CSharp.Lib.ExecutionContext;

[BeforeScenario]
public void BeforeScenario(ExecutionContext context)
{
    String scenarioName = context.CurrentScenario.Name;
    //Code for before scenario
}

[AfterSpec]
public void AfterSpec(ExecutionContext context)
{
    Specification specification = context.CurrentSpecification;
    //Code for after spec
}

@BeforeScenario
public void loginUser(ExecutionContext context) {
    String scenarioName = context.getCurrentScenario().getName();
    // Code for before scenario
}

@AfterSpec
public void performAfterSpec(ExecutionContext context) {
Specification currentSpecification = context.getCurrentSpecification();
    //Code for after spec
}

beforeScenario(function (context) {
    var scenario = context.currentScenario
    // Code for before scenario
});

afterSpec(function (context) {
    var specification = context.currentSpec
    //Code for after spec
});

from getgauge.python import before_step, after_scenario

@before_step
def before_step_hook(context):
    print(context)

@after_spec
def after_spec_hook(context):
    print(context)

before_spec do |execution_info|
    puts execution_info.inspect
end

after_spec do |execution_info|
    puts execution_info.inspect
end

Filtering Hooks execution based on tags¶

You can specify tags for which the execution hooks can run. This ensures that the hook only runs on scenarios and specifications that have the specified tags.

// A before spec hook that runs when tag1 and tag2
// is present in the current scenario and spec.
[BeforeSpec("tag1, tag2")]
public void LoginUser() {
    // Code for before scenario
}

// A after step hook runs when tag1 or tag2
// is present in the current scenario and spec.
// Default tagAggregation value is Operator.AND.
[AfterStep("tag1", "tag2")]
[TagAggregationBehaviour(TagAggregation.Or)]
public void PerformAfterStep() {
    // Code for after step
}

// A before spec hook that runs when tag1 and tag2
// is present in the current scenario and spec.
@BeforeSpec(tags = {"tag1, tag2"})
public void loginUser() {
    // Code forbefore scenario
}

// A after step hook runs when tag1 or tag2
// is present in the currentscenario and spec.
// Default tagAggregation value is Operator.AND.
@AfterStep(tags = {"tag1", "tag2"}, tagAggregation = Operator.OR)
public void performAfterStep() {
    // Code for after step
}

// A before spec hook that runs when tag1 and tag2
// is present in the current scenario and spec.
beforeSpec(function () {
    //implementation
}, { tags: [ "tag1", "tag2" ]});

// A after step hook runs when tag1 or tag2
// is present in the currentscenario and spec.
// Default tagAggregation value is Operator.AND.
afterStep(function () {
    //implementation
}, { tags: [ "tag1", "tag2" ]});

// A before spec hook that runs when tag1 and tag2
// is present in the current scenario and spec.
@before_spec("<tag1> and <tag2>")
def before_spec_hook():
    print("before spec hook with tag")

// A after step hook runs when tag1 or tag2
// is present in the currentscenario and spec.
// Default tagAggregation value is Operator.AND.
@after_step("<tag1> and <tag2>")
def after_step_hook():
    print("after step hook with tag")

# A before spec hook that runs when
# tag1 and tag2 is present in the current scenario and spec.
before_spec({tags: ['tag2', 'tag1']}) do
    # Code for before scenario
end

# A after step hook runs when tag1 or tag2
# is present in the current scenario and spec.
# Default tagAggregation value is Operator.AND.
after_step({tags: ['tag2', 'tag1'], operator: 'OR'}) do
    # Code for after step
end

ScenarioStore¶

This DataStore keeps values added to memory during the lifecycle of the scenario execution. Values are cleared after every scenario is executed.

using Gauge.CSharp.Lib;

// Adding value
var scenarioStore = DataStoreFactory.ScenarioDataStore;
scenarioStore.Add("element-id", "455678");

// Fetching Value
var elementId = (string) scenarioStore.Get("element-id");

// avoid type cast by using generic Get
var anotherElementId = scenarioStore.Get("element-id");

import com.thoughtworks.gauge.datastore.ScenarioDataStore;

// Adding value
ScenarioDataStore.put("element-id", "455678");

// Fetching Value
String elementId = (String) ScenarioDataStore.get("element-id");

// Adding value
gauge.dataStore.scenarioStore.put(key, value);

// Fetching Value
gauge.dataStore.scenarioStore.get(key);

# Import Package
from getgauge.python import data_store

# Adding value
data_store.scenario["key"] = value
# OR
data_store.scenario.key = value

# Fetching Value
data_store.scenario["key"]
# OR
data_store.scenario.key

// Adding value
scenario_store = DataStoreFactory.scenario_datastore;
scenario_store.put("element-id", "455678");


// Fetching Value
element_id = scenario_store.get("element-id");

SpecStore¶

This DataStore keeps values added to memory during the lifecycle of the specification execution.

Values are cleared after every specification is executed.

using Gauge.CSharp.Lib;

// Adding value
var specStore = DataStoreFactory.SpecDataStore;
specStore.Add("element-id", "455678");

// Fetching Value
var elementId = (string) specStore.Get("element-id");

// avoid type cast by using generic Get
var anotherElementId = specStore.Get("element-id");

// Import Package
import com.thoughtworks.gauge.datastore.SpecDataStore;

// Adding value
SpecDataStore.put("key", "455678");

// Fetching value
String elementId = (String) SpecDataStore.get("key");

// Adding value
DataStore specStore = gauge.dataStore.specStore.put(key, value);

// Fetching value
DataStore specStore = gauge.dataStore.specStore.get(key);

# Import Package
from getgauge.python import data_store

# Adding value
data_store.spec["key"] = value
# OR
data_store.spec.key = value

# Fetching value
data_store.spec["key"]
# OR
data_store.spec.key

// Adding value
spec_store = DataStoreFactory.spec_datastore;
spec_store.put("element-id", "455678");

// Fetching Value
element_id = spec_store.get("element-id");

SuiteStore¶

This DataStore keeps values added to memory during the lifecycle of the entire test suite execution.

Values are cleared after the entire test suite is executed.

using Gauge.CSharp.Lib;

// Adding value
var suiteStore = DataStoreFactory.SuiteDataStore;
suiteStore.Add("element-id", "455678");

// Fetching Value
var suiteStore = DataStoreFactory.SuiteDataStore;
var elementId = (string) suiteStore.Get("element-id");

// Avoid type cast by using generic Get
var anotherElementId = suiteStore.Get("element-id");

// Import Package
import com.thoughtworks.gauge.datastore.SuiteDataStore;

// Adding value
SuiteDataStore.put("element-id", "455678");

// Fetching value
String elementId = (String) SuiteDataStore.get("element-id");

// Adding value
DataStore suiteStore = gauge.dataStore.suiteStore.put(key, value);

// Fetching value
DataStore specStore = gauge.dataStore.suiteStore.get(key);

# Import Package
from getgauge.python import data_store

# Adding value
data_store.suite["key"] = value
# OR
data_store.suite.key = value

# Fetching value
data_store.suite["key"]
# OR
data_store.suite.key

// Adding value
suite_store = DataStoreFactory.suite_datastore;
suite_store.put("element-id", "455678");

// Fetching Value
suite_store = DataStoreFactory.suite_datastore;
element_id = suite_store.get("element-id");

Common Gauge project files¶

Regardless of the language plugin used, few common files and directories are created when a Gauge project is initialized.

The following are the common files and directories in the Gauge project structure:

• env

• logs

• specs

• manifest.json

├── env
│  └── default
│     └── default.properties
├── logs
├── manifest.json
├── specs
   └── example.spec

{
  "Language": "<language>",
  "Plugins": [
    "html-report"
  ]
}

{
  "Language": "<language>",
  "Plugins": [
    "html-report",
    "xml-report"
  ]
}

Language-specific project files¶

When the Gauge project is initialized, depending on the language plugin used, language-specific files are created in the project.

The following project structure shows the project structure for the selected language when used for creating a Gauge project.

├── foo.csproj
├── foo.sln
├── manifest.json
├── packages.config
├── StepImplementation.cs
│
├── env
│   └───default
│           csharp.properties
│
├───packages
    └───<Nuget Package Binaries>
├───Properties
│       AssemblyInfo.cs
│
└───specs
        example.spec

├── manifest.json
├── libs
└── src
    └── test
        └── java
            └── StepImplementation.java
├── env
    └── default
        └── java.properties
└───specs
    example.spec

├── manifest.json
└── tests
        └── step_implementation.js
├── env
    └── default
        └── js.properties
└───specs
        example.spec

├── manifest.json
└── step_impl
        └── step_impl.py
├── env
    └── default
        └── python.properties
└───specs
    example.spec

├── manifest.json
├── env
│   └── default
│       └── ruby.properties
└── step_implementations
    └── step_implementation.rb
└───specs
        example.spec