Fixtures vs Factories

Many web frameworks integrate fixtures: a mechanism to define sample data to be loaded in the database for testing. The format of choice is often YAML, and the frameworks supplies classes for setting up and removing this data.

But all too often you load data into the database when all you really need is to access sample objects in your test code. Inserting data into the database for each run slows down tests considerably. Not to mention that with JPA and probably other ORMs as well, you are forced to load a lot more data than strictly required for your tests just to satisfy some foreign key constraint. You might try to solve this by exporting data from your production database, but you will invariably encounter another headache as the export does not work as expected, or importing fails because some data needed to satisfy a foreign key constraint is missing.

Fixtures are not parametrizable, so you are forced to create an entire new set if for some reason you need a different value for some object property in a certain test.

Finally, accessing the database makes your tests also test the database connection: they are not unit tests any more.

Fixtures are often the default choice for no better reason that there is support in the framework; nothing is preventing you from to writing some classes which can build your test specimens without reading data from the database.

Ruby has got Factory Girl, which provides a very concise DSL-ish API to create your objects, but, whatever the programming language, it is easy to write a set of factory methods that can configure the objects you require for testing.

If you wish your tests will become faster, easier to setup and more suitable for test-driven development, you might want to look at this and other methods to avoid touching the database too much in your tests.