PlayNicely.SpecFlow.Executor 1.1.0-beta-260

Play Nicely SpecFlow Executor

The Play Nicely SpecFlow projects provide Gherkin language bindings for PlayNicely.Executor. These bindings allow you to require or uninstall commands, specify package sources and mappings, and set test case projects. These scenarios are designed to support building release tests for Play Nicely npm package projects.

Getting Started

To start using these bindings in a SpecFlow project, install this package, or one of the more specific packages, as a dependency. Then add or update the specflow.json so that the project picks up the bindings.

With this done, you can use the bindings to specify your scenarios.

Install the package

From the Package Manager Console:

Install-Package PlayNicely.SpecFlow.Executor -ProjectName "_your-specflow-project_"

ℹ️ Or use one of the more specific packages such as PlayNicely.SpecFlow.DotNet

Add or Update specflow.json

For SpecFlow to pick up the bindings from external assemblies, they have to be configured in the project's specflow.json file. If the project doesn't already have it, add the item to the root of your SpecFlow project.

Add the external assemblies to the file:

{
    "stepAssemblies": [
        { "assembly": "PlayNicely.SpecFlow.Executor" }
    ]
}

You can now use the step definitions and bindings from Play Nicely.

Working Examples

The PlayNicely.NpmNpx and PlayNicely.Sass projects contain real examples of how to set up your projects and configure test scenarios.

Creating Test Scenarios

This package provides step definitions and hooks to simplify scenario set up. Many scenarios require a test environment and, if a test fails, to output any data sent to stdout or stderr.

The test environment hook will run if you tag your features or scenarios with @test-environment. The order of these hooks are determined using the Order property on hook attributes, the values of these are defined in the SpecFlowConts.BindingOrder static class. You can use these to develop downstream hooks that rely on these concepts, e.g. if it needs a TestEnvironmentBuilder.

Step Definitions

This package provides the following step definitions for use in test scenarios.

Given

• Given (command) is installed Ensures that command is on the $PATH in the test environment.
• Given (command) is uninstalled If the command is found on the $PATH, its directory will be removed from the $PATH in the test environment. This simulates the command being unavailable (uninstalled).

When

• When (command line) is executed Executes process based on the command line provided. The command line is parsed based on the Linux shell rules, \ is the escape character and both " and ' are accepted as quotes.

Then

• Then the command should (succeed|fail) Test whether the process exited successfully.

Hooks and Extensions

The EnvironmentBuilderHooks create a TestEnvironmentBuilder before each scenario and stores it in the ScenarioContext. This builder can be accessed using the extension method ScenarioContext.RequireEnvironmentBuilder() and other methods of the TestEnvironmentBuilderExtensions class.

The ExecutionResultHooks checks to see if a scenario failed, and if it did, outputs any ExecutionResult stdout and stderr streams. Steps can Collect the result using the extension method ScenarioContext.CollectResult(result) of the ExecutionResultExtensions class (this collection is already done for Play Nicely defined steps). This class provides extensions for accessing the execution result, including results that include a context.

The DisposableExtensions allow scenarios to create disposable resources and have them disposed after the scenario finishes. Use the ScenarioContext.MarkForDisposal(disposable) method for this purpose.

Constants

The SpecFlowConsts class defines constants for tags and binding order.