Explicitly allowing default property behaviour on a strict Fake

The default read/write behaviour of a faked property is very useful, however, it seems that there is no way to allow it on a strict Fake by explicitly calling any available configuration method.

A solution could be adding a generalization of the DoesNothing method (UsesDefaultBehaviour ?), so allowed calls could be configured like this:

var i = A.Fake<IInterface>(o => o.Strict());

A.CallTo(() => i.Property)
	.UsesDefaultBehaviour();
A.CallToSet(() => i.Property)
	.UsesDefaultBehaviour();

It would be even more convenient if a dedicated method wrapping both getter and setter was also added:

var i = A.Fake<IInterface>(o => o.Strict());

A.CallToProperty(() => i.Property)
	.UsesDefaultBehaviour();

[blairconrad]

@PiotrKlecha, I don’t really understand how you wouldn’t know when to change a method’s behaviour, since you would know if you are making a call to change the behaviour between test phases.

It’s a bit of an abuse, but worst case, you could check a flag inside a WhenArgumentsMatch matcher (https://fakeiteasy.readthedocs.io/en/stable/argument-constraints/#overriding-argument-matchers)

A.CallTo(() => fake.Bar)
    .WhenArgumentsMatch(args => shouldStillDoNonStandardBehaviour)
    .Throws<Exception>();

And then flip the flag when you want the behaviour to revert.

Regardless, I think this still seems like a very very edge case, and making use of the existing tools is a better solution than adding such a niche operation to the main library.

[PiotrKlecha]

@blairconrad, I meant that a test using a limited call specifier like Once is more likely to fail in an unexpected way if the production code changes and calls the configured method a different number of times. Or it may not detect that additional calls are not properly caught, because they will not throw exceptions at all.

The suggested ‘abuse’ actually seems to be quite reasonable. Too bad it won’t help with strict Fake property configuration 😞