Supersimple Mock/Fake Proxy vs handrolled

fake-vs-stub.cs

/* using FakeItEasy and Cone */

interface ICandy { }
interface ICandyShop 
{
	ICandy GetTopSellingCandy();
	void BuyCandy(ICandy candy);
}

class SweetTooth
{
	public void BuyTastiestCandy(ICandyShop shop) {}
}

//http://fakeiteasy.readthedocs.io/en/stable/quickstart/
public class SweetToothTests
{
    public void BuyTastiestCandy_should_buy_top_selling_candy_from_shop()
	{
		// make some fakes for the test
		var lollipop = A.Fake<ICandy>();
		var shop = A.Fake<ICandyShop>();

		// set up a call to return a value
		A.CallTo(() => shop.GetTopSellingCandy()).Returns(lollipop);

		// use the fake as an actual instance of the faked type
		var developer = new SweetTooth();
		developer.BuyTastiestCandy(shop);

		// asserting uses the exact same syntax as when configuring calls—
		// no need to learn another syntax
		A.CallTo(() => shop.BuyCandy(lollipop)).MustHaveHappened();
	}

	public void look_ma_no_mocks() {
		var lollipop = new Lollipop();
		var shop = new TestableShop { HandleGetTopSellingCandy = () => lollipop }

		var developer = new SweetTooth();
		developer.BuyTastiestCandy(shop);
		
		var buyCandy = MethodSpy.On(ref shop.HandlyBuyCandy, candy => Check.That(() => candy == lollipop));
		Check.That(() => buyCandy.HasBeenCalled);
	}
}

class Lollipop : ICandy { }

class TestableShop : ICandyShop
{
	public Func<ICandy> HandleGetTopSellingCandy = () => null;
	public ICandy GetTopSellingCandy() => HandleGetTopSellingCandy();

	public Action<ICandyShop> HandlyBuyCandy = candy => {};
	public void BuyCandy(ICandy candy) => BuyCandy(candy);
	
}

Maybe I'm missing something, but if the goal of the test is "BuyTastiestCandy should buy the top-selling candy from the shop", and if Shop has both BuyCandy(candy) and GetTopSellingCandy() : candy, then the interaction with Shop already too complicated. Instead, add method Shop.BuyTopSellingCandy() and then we have a single-method interaction.

var candyShop = Substitute.For<ICandyShop>();
var developer = new SweetTooth();

developer.BuyTastiestCandy(shop);

candyShop.Received().BuyTopSellingCandy();

I don't understand the look_ma_no_mocks() version at all, but maybe that's just because I don't speak C# natively, and so I'm not used to reading it that way. It looks like it's using hand-rolled stubs to simulate mocks (I still haven't written this article). In that situation, you are forced to know the side-effect of "buy top-selling candy" in order to detect it! For example, as you did it, one could split "buy top-selling candy" into "find top-selling candy" and "buy candy", so that you can verify which candy was bought. Sigh. "Pretend the top-selling candy is lollipop, so that I can check that that's the one you buy." Seems very indirect compared to simply "buy the top-selling candy, whatever it is, because I don't care what it is."

i agree with your design critique, I simply took the sample from the FakeItEasy quickstart to have something to contrast framework driven vs hand-rolled stubs :)

My single line of argument here is essentially that the hand rolled stub pays for itself if you're wiring up similar interactions more than once.
Most people and teams I've seen routinely get there. And in that scenario the amortized cost of handrolling is actually lower than the implicit implmentation hiding in all the mocking code.

So ignoring the obvious design problem above and looking at the implementation they're both equivavlent in the "pretend lollipop is the top selling thing and that is was bought by the sweet-tooth".

the non mock version simply utilizes lambdas instead of setting expectations. One is already in the context of C# the other is in the context of a specific framework.

What happens to is that the stub version can easily accomodate both strict and lenient mocks, where the mocking framework often starts piling on additional syntax and configuration options to handle those cases.

What I commonly see is people going so far down that route that the length of the first expectation becomes more verbose than the declaration and implementation of a separate (reusable) stub would have been.

Hm. I'm not sure we can separate the one from the other. I didn't entirely understand what you described, so I might need a different example. I thought you were talking about the difference between using a test doubles library and hand-rolling, but I have the feeling that it's being conflated here with the difference between method expectations and stubs. Even so, in this example, I see a test where method expectations are awkward and doing their job: they detect an interaction that can be easily simplified. That's the point of method expectations as a design tool.

When programmers react to complicated method expectations by changing the test, they miss one of the points of doing TDD.

I do love using lambda expressions in place of library-rolled stubs for one-method interfaces, though. That kicks ass.

    @Test
    public void productFound() throws Exception {
        final Price matchingPrice = Price.cents(795);

        final SellOneItemController controller
                = new SellOneItemController(
                        barcode -> Optional.of(matchingPrice));

        Assert.assertEquals(
                new ProductFoundMessage(matchingPrice),
                controller.onBarcode("12345")
        );
    }