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

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