PlayNicely.SpecFlow.DotNet 1.2.0-beta-299

Play Nicely SpecFlow.DotNet

This package extends the Play Nicely SpecFlow bindings for dotnet testing. It provides step definitions for NuGet package sources and mappings, dotnet build, and testing the output of that process, including what errors occurred, if any.

Getting Started

To start using these bindings in a SpecFlow project, install this package 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.DotNet -ProjectName "_your-specflow-project_"

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 assembly to the file:

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

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

Creating Test Scenarios

A typical test scenario involves setting up (NuGet) package sources and mappings, performing a dotnet build and then asserting the execution result context, for dotnet related build properties, e.g. projects built, targets run, errors that occurred, etc.

Step Definitions

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

Given

• Given packages under test are output to (directory) and filenames match (pattern) This creates a NuGet package source and mapping, with a best default fallback source.

When

• When (project) is built This attempts to load a project from a TestSuite, then execute dotnet build on that project.

Then

• Then project (project) contains directory (directoryPath) Assert that the project.WorkingDirectory contains a directory at directoryPath.
• Then "project (project) contains file (filePath) Assert that the project.WorkingDirectory contains a file called filePath.
• Then (errorCode) should be in the list of errors Assert that the errorCode should be in the DotNetExecutionContext.Errors collection.
• Then target (targetName) should not run Assert that the (MSBuild) <Target/> with the name targetName did not run as part of the build.
• Then target (targetName) should run Assert that the <Target/> with the name targetName did run as part of the build.
• Then target (targetName) should run (times) times? Assert that targetName ran exactly times number of times.
• Then the project contains directory (directoryPath) Same as Then project (project) contains directory assertion, except that the project to check is inferred. To infer a project, it must be the only project built.
• Then the project contains file (filePath) Same as Then project (project) contains file assertion, except that the project to check is inferred. To infer a project, it must be the only project built.

Test Suites

dotnet tests typically require a number of pre-defined test (csproj) projects. The When (project) is built step requires a way to load these test projects, to do that a test suite needs to be defined. Derive from the TestSuite class, set the ResourceNamespaceType, the full name of which is the base name for all test case project resources.

Once derived, use a hook and call extension method ScenarioContext.SetSuite to set the suite for the subsequent scenario.