Provide an alternative to ClearConfiguration

In #1764, @PiotrKlecha raised a concern about how ClearConfiguration removes the strictness from a strict Fake, and this was unexpected, since the strictness is (usually) applied at creation time, and so it feels like it’s an intrinsic aspect of the Fake, rather than some additional configuration that’s added on after.

In that case, it turned out that there was a way to reformulate @PiotrKlecha’s tests so ClearConfiguration wasn’t needed, but the bell couldn’t be unrung. @thomaslevesque and I discussed how ClearConfiguration worked and how it’s very difficult to predict what it would do from the outside. Complicating factors that we identified

• configuration to make the Fake strict, to have it wrap another object, or to have it call base methods are typically applied at creation time, and may not be what the client has in mind when clearing configuration
• configuration to make a Fake act strict or to have it call a base method can be applied after creation time, although it’s less convenient. Therefore retaining particular kinds of rules may not be easy.
• implicit creation options further confound the picture. Since they’re not in front of the user, they may be relied on without them knowing about it, so removing them from the configuration might be a surprise (conversely, not removing them might be a surprise).

We decided that the ClearConfiguration feature was of minimal benefit, and was causing at least a little confusion, so should be removed. Official guidance was updated to indicate that the preferred mechanism is just to throw the Fake away and make a new one with the desired configuration.

Later, @rmiller333 raised #1767, describing a situation where throwing away the configuration was not practical, since the Fakes were created by a Dependency Injection system and had lifetimes longer than a test. We proposed 3 potential workarounds in that case

1. mark the Fakes as transient somehow. This would depend on the DI container being used
2. instead inject objects that proxy the Fake services, and swap out their implementation between tests
3. use DoesNothing to configure every method on the Fakes. It’s not quite the same as removing configured rules (and would break strictness, wrapping, and base-method calling), but might work in some circumstances.

It’s been about a month with no feedback, and we don’t know what, if anything, was of use to @rmiller333.

And two days ago @afelinczak commented in #1768, essentially echoing the problem with long-lived Fakes that are created by a Dependency Injection container.

I think removing ClearConfiguration is causing enough of a concern that we should revisit and see if we can’t provide a better alternative, at least.

[thomaslevesque]

slightly uneasy about introducing the cost of copying away initial state every time we construct a Fake just to support the users of ResetToInitialConfiguration

I suspect that cost is not very significant. We’d have to do some benchmarks to make sure, of course.

Anyway, if it turns out to be a problem, maybe we could just make saving the state explicit? e.g.

var foo = A.Fake<IFoo>();
// maybe add some rules here
...

// Make a snapshot of the fake
var snapshot = Fake.CreateSnapshot(foo);
...

// Restore the snapshot
Fake.RestoreSnapshot(foo, snapshot)

This would provide the desired behavior, and would also be more flexible, since you could have multiple snapshots, and revert the fake to any previous state, not just the initial state.

[blairconrad]

In DI scenario we would likely to need only one snapshot.

Thanks. To be honest, I’m not sure when anyone would ever need more than one…

If snapshots will live as separate objects it will be hard to use them (possibly they also need to be added to DI wrapped in container object)

Makes sense.

Also in multi snapshot scenario if stored on fake object itself, we could either select snapshot by name or index.

But then the code selecting the snapshot will need to know the proper name or proper index, requiring a sharing of information between snapshot creation and snapshot selection. I suppose a “well-known string” could be reused around the test application, which would be easier than obtaining a custom snapshot object, but it’s kind of gross. Consolidating the snapshot names would be equivalent to making the snapshot objects themselves accessible from multiple locations.

---

Assuming the usage is typical, I’m in favour of attempting an opt-in scenario, where a snapshot would be created and stored in the Fake and then could be reverted to later.

@thomaslevesque, you proposed the multiple-snapshots-as-separate-entities scenario, which is more flexible and powerful, but I’m not sure it is worth paying for. What do you think?