Scoped value formatters

[FLAMESpl]

Background and motivation

This feature is about allowing adding custom IValueFormatters to AssertionScope. In my development I discovered that I need to selectively customize formatting of an object based on the test's context. There is an option to remove once added formatter but it will not play nicely if tests would be executed simultanously. Having scoped formatters have a side bonus of reusable parametrizing formatter instances.

API Proposal

First make IFormatterCollection interface.

public interface IFormatterCollection : ICollection<IValueFormatter>
{
}

Then add it to AssertionScope:

public class AssertionScope
{
    public IFormatterCollection Formatters { get; } = // initialize from parent scope
}

Formatter API remains unchanged. Internally it will utilize IFormatterCollection for sake of coherence.

API Usage

using (var scope = new AssertionScope())
{
   scope.Formatters .Add(new MyCustomFormatter())
   // some assertions
}

Alternative Designs

Alternative would be to add a custom key-value store in AssertionScope that could be read inside a IValueFormatter.

Risks

None I can think of.

Are you willing to help with a proof-of-concept (as PR in that or a separate repo) first and as pull-request later on?

Yes, please assign this issue to me.

[dennisdoomen]

Maybe scope.UsingFormatter(new MyCustomFormatter()) is nicer?

[FLAMESpl]

It is also an option, this way collection of formatters could be internal.

[dennisdoomen]

I'm fine with that. What about you @jnyrup ?

[jnyrup]

I like the proposal of having scoped formatters 👍

As the signature is Formatter.ToString(object value, FormattingOptions options = null) placing the scoped formatters on FormattingOptions might be a good place?

When retrieving all formatters in Formatter.Format it will then search in scoped custom formatters, static custom formatters and lastly static default formatters.

Perhaps we should also move the current Formatter.CustomFormatters to FormattingOptions?
This should be doable without introducing any breaking changes, by forwarding the existing AddFormatter and RemoveFormatter.
The statically set custom formatters will then be set on the static AssertionOptions.FormattingOptions and the scoped ones will be set on AssertionScope.FormattingOptions.

To set a scoped formatter you'll only have to do

using var scope = new AssertionScope();
scope.FormattingOptions.AddFormatter(new MyCustomFormatter());

[dennisdoomen]

That sounds like a great idea. Let's go for that.

[dennisdoomen]

@FLAMESpl are you still interested in this one?

[ChristoWolf]

@dennisdoomen: I would certainly be interested 😃

[dennisdoomen]

I meant in implementing this.

[ChristoWolf]

Ah whoops, I misunderstood.

[IT-VBFK]

I am willing to take that, if @FLAMESpl doesn't want to.

[ITaluone]

Should a nested AssertionScope pick up all previous defined scoped formatters?

[dennisdoomen]

Everything that is associated with an AssertionScope flows in the nested scopes.

[ITaluone]

Ok, the tricky part is how to determine which scoped formatters to remove at scope dispose 🤔

[dennisdoomen]

Yeah, it means that the scope needs some state on which scope has added a particular formatter.