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);
	
}

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")
        );
    }