Thursday, June 21. 2007PHPDBUnit - Testing DB interaction with PHPUnitTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
It will be integrated with phpunit. I am not entirely sure if it will be downloaded as part of the same package yet or not. Sebastian Bergmann has been kind enough to offer the phpunit svn server on which to store phpdbunit. In the event that it is not in the same package I would imagine that you would be able to install it from the phpunit pear channel.
The PHPDBUnit_TestCase extends PHPUnit_Framework_TestCase. In order to assist in doing database testing on already existing test cases I also plan to implement a tester interface and a corresponding set of classes that will allow you to compose db tests into your existing test cases without having to change which class your test case extends from.
My idea is to create a branch for DBUnit development (as a copy from PHPUnit 3.1) and ship DBUnit bundled with PHPUnit (say, as of PHPUnit 3.1.X) as soon as Mike deems it stable.
Once DBUnit is stable, the DBUnit code will be moved from the branch into PHPUnit's main development branch and the separate DBUnit branch will be closed.
Might be nice for acceptance testing, but I don't see why you would want to talk to a real db during unit testing. It's just too slow, and if you need anything resembling a biggish dataset for a *unit* test, your unit tests aren't fine-grained enough.
Mocking the database is really where you want to go. Redirect the connection logic to give a mock connection object back that basically does string compares to pick which of a handful of precooked result sets (in-memory arrays) to return. It'll cost you an hour or so to rig up some baseclasses, and keeping everything in memory (and not having to truncate tables) makes sure that your unit tests keep flying. Also, having your datasets in the code will force you to think about your unit tests once they get large - usually that's a refactoring smell I used database-based unit testing once, when I just started with XP 10 years ago, and I'll never go back there.
As soon as you start trying to mock queries you begin to lose the ability to ensure that the queries you are writing are correct. In my opinion it is just as important to ensure your queries are returning what you expect as it is to ensure your functions are returning what you expect. String comparison may work for smaller non data intensive apps but if returning the correct data is vital then having code that specifically tests your database is important.
The primary motivation for me to work on this is we have thousands of lines of code in the app I work on that query a roughly 16 GB database. It is very common for us to re-factor our queries (especially our reporting queries) with the goal of speeding them up. When we make these changes we need to be able to test and make sure that we are still returning the data we expect. While database unit testing might not work well for some apps or some people it is a useful tool to have in your testing arsenal.
I have made an initial commit of this functionality into the dbunit branch of phpunit: http://www.phpunit.de/changeset/961
It is by no means complete, however the basics of the functionality are there. When I get a little bit more free time and clean up a few more things I will post an announcement and some instructions on how to use it.
It appears that my code was eaten. You can find complete examples (and more accurate ones) at:
http://www.ds-o.com/archives/63-PHPUnit-Database-Extension-DBUnit-Port.html |
Paying for the Site
QuicksearchCategoriesDaily ReadsThe PHP WTF Sebastian Bergmann Wez Furlong Tom Sommer Tobias Schlitt Chris Shiflett Ben Ramsey adam trachtenberg Sklar george schlossnagle Dynamically Typed (Harry Fuecks) John Coggeshall John Lim Marco Tabini PHP Application Tools Planet PHP PHPCommunity.org |

