As a developer, I want lots of awesome testing capabilities to be at my fingertips with less effort, as always. For this round, I want to be able to drop certain phrases into my SpecFlow feature files and be able to rely on certain injected objects to behave in predictable ways. Some steps can be convention-driven, while others can be static. More research needs to be done into what common tasks could be represented here.
Another important feature is support for multiple IoC providers. I want integration with IoC to be as seamless as possible, but I also want the ability to be explicit when it's called for. For example, I'd like to be able to combine provider-specific tags with provider-agnostic steps:
@autofac # <-- specific
Scenario: Unicorn Repository Lookup
Given I have registered the data package # <-- agnostic
And I have created the container # <-- agnostic
When I try to resolve a repository for unicorns # <-- agnostic
Then my unicorn repository should exist
And I should have 0 errors
Since most steps are going to be domain-specific in their wording, only a few canned step bindings can be provided for scenarios like these. The example from above is just:
And I have created the container
I do, however, think that the above feature could result in a container state object that can handle the provider tag, and can be used for strategy-driven IoC integration by exposing methods for registration and resolution.
I would also like to combine support for explicitly calling out your IoC provider for scenario variants, like:
Scenario Outline: Multi-provider Unicorn Repository Lookup
Given I have registered the data package with <container name>
And I have created the <container name> container
When I try to resolve a repository for unicorns
Then my unicorn repository should exist
And I should have 0 errors
Examples:
| container name |
| Autofac |
| Ninject |
| Windsor |
If possible, I'd also like to avoid making any dependencies on any container-specific Patterns assemblies; if you run Install-Package Patterns.Testing.Autofac then Install-Package Patterns.Testing.SpecFlow but then you used the @ninject tag somewhere, you're gonna have a bad time... so this would introduce some brittleness, but the upside is: developers that want this kind of drop-in support but only want to actually use 1 or 2 of the providers available in the code-patterns spectrum can have it, without the superfluous references to other flavors.
EDIT: see below for scope changes
As a developer, I want lots of awesome testing capabilities to be at my fingertips with less effort, as always. For this round, I want to be able to drop certain phrases into my SpecFlow feature files and be able to rely on certain injected objects to behave in predictable ways. Some steps can be convention-driven, while others can be static. More research needs to be done into what common tasks could be represented here.
Another important feature is support for multiple IoC providers. I want integration with IoC to be as seamless as possible, but I also want the ability to be explicit when it's called for. For example, I'd like to be able to combine provider-specific tags with provider-agnostic steps:
Since most steps are going to be domain-specific in their wording, only a few canned step bindings can be provided for scenarios like these. The example from above is just:
And I have created the containerI do, however, think that the above feature could result in a container state object that can handle the provider tag, and can be used for strategy-driven IoC integration by exposing methods for registration and resolution.
I would also like to combine support for explicitly calling out your IoC provider for scenario variants, like:
If possible, I'd also like to avoid making any dependencies on any container-specific Patterns assemblies; if you run
Install-Package Patterns.Testing.AutofacthenInstall-Package Patterns.Testing.SpecFlowbut then you used the@ninjecttag somewhere, you're gonna have a bad time... so this would introduce some brittleness, but the upside is: developers that want this kind of drop-in support but only want to actually use 1 or 2 of the providers available in the code-patterns spectrum can have it, without the superfluous references to other flavors.EDIT: see below for scope changes