Exposing IServiceProvider param closer to surface to enable IDisposable management and/or AutoFixture integration

Oct 24, 2013 at 12:44 AM
Edited Oct 24, 2013 at 12:58 AM
I'm puzzling whether it would be possible and/or you have plans and/or anyone has requested to push out an IServiceProvider e.g. out as far as StepDefinitions

If this was possible, I'd seek to push in an IServiceProvider Adapter based on AutoFixture.

This would allow TickFactAttribute to begin to e.g.
  • allow arbitrary ctor args on StepDefinition classes (and customization of strategies for building same)
  • allow threading shared state from a CreateBrowserSteps to ObserveBrowserSteps
  • allow stashing state (fixture.Inject) for later retrieval (fixture.Create) if e.g. wanting to feed a result of a Given/When thru to a Then observation (likely concurrently an abuse of AF and TickSpec)
  • allow usage of AutoFixture's DisposableTrackingCustomization to track all instances created under its control that are IDisposable for controlled Disposal (e.g. per run in a 'finally' ohase of a TickCommand) (This would seem to be a good way to avoid getting TickSpec Core into the business of IDisposable management)
There may also be possibilities using techniques like AutoFixture.xUnit employs to declaratively specify Customizations via Attributes on Facts (actually Theory)

Havent tried very hard to grok whether the current place the ServiceProvider is instantiated is 'just where it landed' or the result of a set of interacting forces driving it to be just so (kinda the way).

Not looking for a massive wiki article - just a few pointers will be dandy and I'll know what direction to spike.

I dont necessarily think that leveraging AF's Anonymous object building (much less abusing it as a bag of state) is necessarily a good idea in the context of using TickSpec for ATDD. The above is a just a general thinking out loud dump.

The core driver for me thinking about this is that I'm want some way to have Disposal managed declaratively without BeforeScenarios and/or the busywork or psychic weight of ensuring every module full of StepDefinitions definitely does an appropriate teardown (for instance right now I have a registry of IDisposables and each module registers itself in there and the first AfterScenario triggers a correctly ordered [in reverse order of construction] Disposal.).
Oct 24, 2013 at 1:11 AM
Edited Oct 24, 2013 at 1:12 AM
I use the IServiceProvider to manage instances of classes when running scenarios, i.e. when you run a scenario you may have one or more classes with step definitions that it will invoke and you only want one instance of each per scenario.

It might be useful for cleanup to call Dispose after each scenario on any class that implements IDisposable, but this would only be useful for classes - not modules.

Another suggestion has been that you could return values from a step and receive those values as arguments in subsequent steps, allowing you to weave state across functions in modules without using globals. In which case again once a scenario is complete any state that implements IDisposable could be disposed. Would that be interesting?
Oct 24, 2013 at 1:46 AM
I'd be talking of replacing the SP (though any substitute it would need to preserve the single instance per type semantics of stuff to add up) (i.e. if implementing it as an AutoFixture Adapter, getInstance would need to wire to fixture.Freeze as opposed to fixture.Create

If the substitution possibility was there, Disposal (and ownership) could be pushed out

Very much aware of the return values idea - as alluded to, using AF fixture.Inject to stash return values and AF fixture.Freeze to synthesize args that are suitably Attributed or match some suitable convention (and/or don't match Regex Groups).

If one was to so a straightforward impl of supporting Step Instance Disposal [via some extensions to built-in ServiceProvider], one important thing for me is that Disposal order be reverse of Create order

I guess the key issue here is that flowing state, flowing Customizable Anonymous Builder capability across GWT, disposing step defs, allowing synthesis of step ctor args etc. is too many concerns.

It would seem that exposing a pluggable ServiceProvider, IDisposable (and some related things) is perversely simpler to do than actually trying to figure out The Real Problem(s) and support that OOTB

I'll sleep on it and see if I can at least trim to my requirements to a set of stuff I a) demonstrably need and b) think is a good idea for TickSpec

(as opposed to trying to work backwards from what you can do if one composes an AF golden hammer with a TS one !)