Fixtures that build the object graph beat a database dump

The usual way to give an integration test some data is a SQL dump loaded before the suite, or an XML dataset per test case. Both describe rows. A year later nobody can say which of the 400 rows a given test actually depends on, and adding a NOT NULL column means editing a fixture file that no longer means anything to anyone.

class OrderFixtures
{
    public static function paidOrder()
    {
        $order = self::pendingOrder();
        $order->markPaid(new DateTime('2014-07-01 10:00:00'));

        return $order;
    }

    public static function pendingOrder()
    {
        $order = new Order(self::customer(), new Money(4900, 'TRY'));
        $order->addLine(self::product('SKU-1140'), 2);

        return $order;
    }
}

// in the test, the precondition is one readable line
public function testAnUnpaidOrderCannotBeShipped()
{
    $order = OrderFixtures::pendingOrder();

    $this->setExpectedException('OrderNotPayable');
    $this->shipping->dispatch($order);
}

A factory method builds the graph through the domain’s own constructors, so a fixture cannot express a state the application could never reach — which is exactly what a hand-written row can do, and does, producing tests that pass against data the system would never have created. Renaming a column then breaks one mapping rather than forty XML files. The named methods are the other half of it: pendingOrder() says what the test needs where orders.xml says nothing at all. What it costs is that setup now runs application code, so a bug in Order makes unrelated tests fail confusingly, and a fixture quietly accumulating options is on its way to becoming a second implementation of the domain. Keep them named after states rather than parameterised into a general builder.