In my previous post I already mentioned Sebastian Jerzy Wilczyński (@dj_sebastian_w) and his uncon session "Unit Testing for Databases using fixtures and phpunit". It made me wonder how much difference it would make if you use fixtures instead of testing database interactions using predefined sets of data. Since I work a lot with Zend Framework I was looking at how I could use fixtures and mock objects to follow Sebastian's guidelines. So I gave it a try. This is what I came up with.

He illustrates with some example code - a set of database data (the fixtures) and sample tests that use the Zend Framework's mapper and table gateway functionality to work with the tables. His test then mocks out the DbTable class for the "Order" object and forces a return of the database fixture data.

So I started thinking that there must be a way to use fixtures for the database the same way as when testing models with PHPUnit Database extension (PHPUnit_Extensions_Database_TestCase). But since PHP does not have multiple inheritance, we can't extend both Zend_Test_PHPUnit_ControllerTestCase and PHPUnit_Extensions_Database_TestCase. So I started out to create a controller test case class that has support for fixtures the same way as the database test case. I mean, how hard can it be?

He dug into the code for the extension and finally came up with a working solution - an abstract class with "_setup" and "_setupDatabase" methods that create what you'll need to perform your tests. A sample test is included in the post to show you it in action.

Doctrine's DataFixtures are a great way to add test data to your application. It's fairly easy to get this going: Create a fixureLoader that extends DoctrineCommonDataFixturesAbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2′s ACL layer. Since there isn't a common way to do this, here is one way on how I implemented this.

His method uses the ContainerAware interface on the fixture loader instance to be able to get at the container for the fixture. This allows you to use the usual ACL handling methods of the framework to provide restrictions based on things like usernames and roles.

The li3_fixtures plugin was my first Lithium plugin ever, and while it works okay, I feel there is a lot I can do to make it better and more flexible. In this post I want to share my ideas for a new fixture plugin and also want to gather feedback from the community to make it even more awesome.

He gives three instance where fixtures can come in extremely useful - making effective model unit tests with predictable data, mocking models with shortcuts to the data and mocking out web services. Want to add in your own suggestions for his refactor? Comment on the post!

From the first of the two tutorials:

A good example of a fixture that makes sense to share across several tests is a database connection: you log into the database once and reuse the database connection instead of creating a new connection for each test. This makes your tests run faster.

This fixture sharing example uses the setUpBeforeClass and tearDownAfterClass methods to create and destroy the connection.

In the second article Sebastian shows how to mock up a sample static function and mock it with the "staticExpects" helper.

Among the features introduced in this new version, the most notable are the support for test dependencies and fixture reuse as well as the possibility to run tests in separate PHP processes for increased test isolation. Please have a look at the ChangeLog for a complete list of changes.

As a teaser, he also mentions the work being done on the code coverage features that will be included in the next release.

Testing_FIT is the PHP and pearish version of Ward Cunningham's FIT http://fit.c2.com. As such it provides an easy to use framework for acceptance software tests.

The package is a simple download and install and gives you four basic fixtures to use Action-, Column-, Row- and Primitve-Fixture (and a Summary-Fixture for stats purposes).