Needs refinement: better testing support and integration

[TheTribe]

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

[TheTribe]

We could probably pull some code out of the old new-tech-lab repo for the Patterns.Inversion assembly defined there; I think there is some dusty code in there that will load new assemblies using a simple, convention-based naming algorithm. It might come in handy when trying to avoid any specific IoC references.

[TheTribe]

On second thought, anything matching the above descriptions can find homes in Patterns.Testing and the IoC-specific variations. After some consideration I don't mind forcing a dependency on SpecFlow from Patterns.Testing et al, since I always use it.