Configuring a call on a strict fake without Returns

Hi, due to issue #899 I upgraded FakeItEasy from version 2.1.0 to 2.3.2 and mentioned a different behavior. In 2.1.0 if a call to a strict fake is configured without a return then the calls to the fake work and the default value is returned. In 2.3.2 there is only an exception with the message “Call to non configured method “Bar” of strict fake”.

In my opinion the new behavior is ok but a better message would be nice, something like: “Call to configured method “Bar” of strict fake has no return specification”

public interface IFoo
{
    bool Bar(string x);
}

[TestMethod]
public void TestMethod1()
{
    var fake = A.Fake<IFoo>(x => x.Strict());
    A.CallTo(() => fake.Bar(A<string>.Ignored)); // In 2.1.0 the default value was returned
    Assert.IsFalse(fake.Bar("Foobar")); // In 2.3.2 an exception is thrown
}

[blairconrad]

Thanks for alerting us, @thunderbird55. The code you have is an error, in that A.CallTo without a directive regarding the method’s behaviour is meaningless.

A.CallTo was always intended to have no effect without such a directive (e.g. Returns, DoesNothing, etc.), and this was remedied when we fixed #556. We do regret that fixing this bug causes some inconvenience for people who’ve been relying on the behaviour. The solution is to specify an action. In this case, I guess you’d want .Returns(false).

If you’re using a modern Visual Studio, consider picking up the FakeItEasy Analyzer, which will warn you of this incorrect usage and give you a chance to correct it before your tests even fail.

[thunderbird55]

As you say, a good part of our resistance is technical: due to the form of the API, it’s not that easy to tell when configuration is done. We say A.CallTo. Maybe we’re done, maybe we aren’t. Things could be done to detect this situation, but at a cost in extra code complexity and runtime performance.

Ok, then I would say let’s close this issue. I thought maybe there is only an additional if necessary.

We’re getting more tangential here, but it’s a shame about ReSharper.

The warning thing is something to consider, but years ago at my Day Job we picked it up and started using it on a legacy project. There are certainly lots of warnings (of course, tunable), but we’ve contented ourselves with cleaning up a file as we touch it (or for truly monstrous files, picking a class of warning at a time within the file) and gradually enjoying the improvement. As time goes by, the heavily-trafficked files get cleaned up very quickly, and the infrequently visited ones less so, but hey, they’re probably infrequently visited because they work well enough, so the approach is working for us.

I totally agree with you. In my former company we had a similar approach. In my current company the philosophy is “don’t change anything”. But better we don’t talk about this because I’m getting angry when I’m thinking about this 😦