Improve interface of Invokes to allow specifing number of calls

Currently it is not possible to directly specify a number of calls when configuring Invokes, e.g. given the following interface:

public interface ITest
{
	int Test(int testNumber);
}

a configuration like:

[Test]
public void Test()
{
	var counter = 0;

	var test = A.Fake<ITest>();

	A.CallTo(() => test.Test(1))
		.Invokes((int testNumber) => counter++)
		.Once();
}

does not compile.

However, all it takes is a cast and it works flawlessly:

[Test]
public void Test()
{
	var counter1 = 0;
	var counter2 = 0;

	var test = A.Fake<ITest>();

	((IAfterCallConfiguredConfiguration<IReturnValueConfiguration<int>>)A.CallTo(() => test.Test(1))
		.Invokes((int testNumber) => counter1++))
		.Once()
		.Then
		.Invokes(() => counter2++);

	test.Test(1);
	test.Test(1);
	test.Test(1);

	Assert.That(counter1, Is.EqualTo(1));
	Assert.That(counter2, Is.EqualTo(2));
}

I suppose this is unintended and the number of calls specification should be available directly, without a cast.

[thomaslevesque]

Perhaps it could be solved by adding types for rules - a rule would be applied if no rule of the same was already applied. That way each new configuration of Returns would overwrite previous ones (same type), but Invokes would apply independently (different type).

Unfortunately, that would be a major breaking change that would impact every current user of FakeItEasy, just to solve a problem very few people have…

I’m sorry I seem so reluctant to accept your suggestions. They’re not necessarily bad ideas, but we need to be very careful when evolving the library. Many users rely on it, and we try to minimize breaking changes. When we do introduce a breaking change, it’s usually:

• either a behavior change (without API change) to fix a behavior that we consider to be a bug (so it’s unlikely anyone relies on it)
• or an API change that will require the user to change their code in order to be able to compile (so they can’t ignore the change)

The change you propose is the worst kind of breaking change : no API change (so existing code will keep compiling without error), but a major behavior change (so existing code will suddenly start to fail at runtime without any apparent reason).

[blairconrad]

This change has also been released as part of FakeItEasy 7.0.0.