Matthias Noback has written up an article on his site covering a tool that's common in many web applications, especially for testing: fixture data. In the post he makes some suggestions about effective ways to use them to provide more "real world" results for tests.

System and integration tests need database fixtures. These fixtures should be representative and diverse enough to "fake" normal usage of the application, so that the tests using them will catch any issues that might occur once you deploy the application to the production environment. There are many different options for dealing with fixtures; let's explore some of them.

He makes four suggestions of ways to handle fixtures:

1. Generate them the "natural" way via interaction with the application and taking a snapshot of the data.
2. Generate them at runtime for the tests, reloading them each time
3. Manual insertion of custom data into the database for all tests
4. Manual insertion of custom data into the database for each test case

He finishes the post by asking a question for those considering using fixture data: do you need them at all? Testing should be isolated from external sources so maybe they're not really needed...

Wojciech Sznapka has a new post to his blog today looking at his creation of fully isolated tests as a part of a Symfony2 application. He talks about two issues he recently solved with testing services in this popular framework.

The most important thing you should provide with your re-usable bundles is unit tests set. Lately I solved two major cases which Symfony2 hasn’t got out of the box: testing services, defined in Dependency Injection Container and running model tests with fixtures in fully isolated environment.

He includes code snippets for both solutions - a BaseTestClass for working with dependency injection testing and a ModelTestCase class that, in the setUp(), loads in the required fixtures so the test can be completely isolated.