Hi Matthew, Thanks for the reply. Your email confirmed what I've read/thought about the tests. I'll look this SimpleTest even tough PHPUnit2 seems to do the job fine. If you have more info (like books, urls, examples) please send me. regards. On 6/2/05, Matthew Weier O'Phinney <matthew@xxxxxxxxxx> wrote: > * mbneto <mbneto@xxxxxxxxx>: > > I am trying the phpunit2 for unit testing but the examples found in > > the documentation are few and do not address, for example, tests when > > database access is involved. > > > > Perhaps this belongs to a more general question (i.e strategies for > > unit testing) so any urls, docs would be great. > > Jason Sweat covered this at php|Tropics, using SimpleTest as the unit > testing framework. I use phpt unit tests (developed for testing php > itself, and used by the PEAR project for regression tests). The > principles are the same regardless of framework, however. > > The fundamental problem is: your code may depend on the results of a DB > operation -- it's primary purpose may even be to perform a DB operation. > While you can test the code, you still need to test whether or not your > code can successfully perform the DB operation as well. A common problem > I find is that I'm building SQL on the fly -- and that process may build > shoddy SQL. It may be building exactly what I designed it to do, but the > RDBMS will never be able to actually utilize the SQL I build. Tests can > help catch these issues. > > Basically, when testing code that interacts with a database, you've got > two basic strategies: (1) test against the DB, or (2) use mock objects. > The latter is a tricky subject, as it assumes you're using a DB > abstraction layer, and because you then have to mimic how that > abstraction layer works. Basically, you end up doing a lot of code > simply to test. > > Which brings us back to (1), test against the DB. > > The way to do this is to have some code that sets up and tears down a > TEST database -- not the one with your live data. It should likely > create and populate any tables you need, and then be able to tear them > down again. The reason behind this is that you can then have a set of > consistent data to test against -- once you run tests, chances are > likely that you've altered the data. Each test you run should tear down > the DB and then recreate and/or repopulate it. > > If you use the phpt unit tests, the place to do this is in your > setup.php.inc file. I then create a file with the raw SQL for > setting up and populating a test table, slurp it in with > file_get_contents, and pass it on to the DB from within a function in > that setup file. Then another function can truncate or delete all > records from the tables utilized. > > The code within the test might then look like this: > > <?php > include_once dirname(__FILE__) . '/setup.php.inc'; > > setupDb(); > // do a test > teardownDb(); > > setupDb(); > // do another test > teardownDb(); > ?> > > That's kind of a long-winded answer to your question, but it's not > something you see a lot of information on. I hope that it helps. > > -- > Matthew Weier O'Phinney | WEBSITES: > Webmaster and IT Specialist | http://www.garden.org > National Gardening Association | http://www.kidsgardening.com > 802-863-5251 x156 | http://nationalgardenmonth.org > mailto:matthew@xxxxxxxxxx | http://vermontbotanical.org > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
