NOTICE. We are in the process of archiving this project as SpecFlow has been Sunset.

SpecFlow End of Life has been announced. We're currently in the process of migrating all of our projects over to Reqnroll.

One learning we've made from this project is that combining the core testing framework and a platform (i.e. Azure Functions) in to the same repository can be painful as the two technologies evolve at different rates, so we've decided to split the features out into two separate repositories.

• Corvus.Testing.ReqnRoll
• Corvus.Testing.AzureFunctions.ReqnRoll

This migration may cause a security warning as Corvus.Testing.AzureFunctions nuget package (from v5.0) is now published by Corvus.Testing.AzureFunctions.ReqnRoll.

New Packages

| Package | NuGet | Description | |-------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------| | Corvus.Testing.ReqnRoll | | Core ReqnRoll testing functionality | | Corvus.Testing.ReqnRoll.NUnit | | NUnit integration for ReqnRoll testing | | Corvus.Testing.ReqnRoll.MSTest | | MSTest integration for ReqnRoll testing | | Corvus.Testing.AzureFunctions | | Core functionality for managing Azure Functions instances | | Corvus.Testing.AzureFunctions.ReqnRoll | | ReqnRoll integration for BDD testing | | Corvus.Testing.AzureFunctions.ReqnRoll.NUnit | | A metapackage that encapsulates the required dependencies when using Corvus.Testing.AzureFunctions.ReqnRoll | | Corvus.Testing.CosmosDb.Reqnroll | | ReqnRoll integration for testing with Cosmos DB v3 SDK (Legacy) |

Corvus.Testing (Deprecated)

This provides a library of useful testing extensions, primarily focussed on SpecFlow operations.

It is built for .NET 6.0, and we support use on both .NET 6.0 and .NET 8.0. (If you require .NET Standard 2.0, use Corvus.Testing v1.)

The SpecFlow specific libraries contain additional bindings; to use these, you will need to add a specflow.json file to any project wishing to use them. Add entries to the stepAssemblies array for each of the Corvus libraries you need to use:

{
  "stepAssemblies": [
    { "assembly": "Corvus.Testing.SpecFlow" },
    { "assembly": "Corvus.Testing.AzureFunctions.SpecFlow" },
  ]
}

Features

This library offers the following features.

Container Bindings (Corvus.Testing.SpecFlow)

Corvus.Testing.SpecFlow can simplify the use of dependency injection. It can automatically create a dependency injection service collection (an instance of the IServiceCollection type defined by the Microsoft.Extensions.DependencyInjection.Abstractions component). It offers your tests an opportunity to populate this collection during the early phases of test execution. It then automatically builds an IServiceProvider from the service collection, and makes this accessible to your test. It disposes the provider at the end, ensuring any dependencies that need to clean up will have their Dispose methods called.

This feature offers two modes: you can either arrange for the service collection to be created, built, and torn down for individual scenarios, or you can create one that is created at the start of a feature, in which the service provider is shared by all scenarios within the feature, and the services are disposed only after all scenarios have run.

In most cases per-scenario mode is better, because it improves isolation between tests. However, if service initialization is particularly slow, feature-level containers might offer a useful escape hatch.

To use per-scenario mode, use the @perScenarioContainer tag. You can either put this on each of the individual scenarios you need, or put it at the top of the feature file, in which case every scenario in that feature will get its own container. To use per-feature mode, put a @perFeatureContainer tag at the top of the feature file. (You cannot use both modes at once.)

To populate the service collection you must write a binding that runs at the appropriate time. For per-scenario collections, it will look like this:

[BeforeScenario("@perScenarioContainer", Order = ContainerBeforeScenarioOrder.PopulateServiceCollection)]
public static void PopulateScenarioServiceCollection(ScenarioContext scenarioContext)
{
    ContainerBindings.ConfigureServices(scenarioContext, services =>
        services.AddLogging()
            .AddSingleton<IStore, FakeStore>());
}

and per-feature collections work in almost exactly the same way, largely just changing "Scenario" to "Feature":

[BeforeFeature("@perFeatureContainer", Order = ContainerBeforeFeatureOrder.PopulateServiceCollection)]
public static void PopulateFeatureServiceCollection(FeatureContext featureContext)
{
    ContainerBindings.ConfigureServices(featureContext, services =>
        services.AddLogging()
            .AddSingleton<IStore, FakeStore>());
}

The method name doesn't matter. It's the attribute that's significant. Note that by specifying the same @perScenarioContainer (or @perFeatureContainer) tag that Corvus.Testing.SpecFlow is looking for, this binding will run for any tests that specify that tag. If you want to use this container feature in multiple tests but you want to use different service configuration in different tests, you can define your own tag, e.g. your feature file might start:

@perScenarioContainer
@adminTestContainerInitialization

And then you would specify that more specialized @adminTestContainerInitialization tag in your bindings instead of @perScenarioContainer.

To obtain services from the DI container, you can write code like this:

IServiceProvider serviceProvider = ContainerBindings.GetServiceProvider(this.scenarioContext);
MyService svc = this.ServiceProvider.GetRequiredService<MyService>()

The ContainerBindings.GetServiceProvider method is overloaded, accepting either a ScenarioContext or a FeatureContext. If you used the @perScenarioContainer tag you should pass the scenario context as the example above does, but if you're using @perFeatureContainer pass the feature context instead.

GetServiceProvider will work from inside any step, whether it's Given, When, or `The