I've looked through the various questions on unit testing but can't find one that specifically answers this question.
I've got several PHP classes that contain functions that look like this:
static function _setSuspended($Suspended, $UserID)
{
try {
$con = Propel::getConnection();
$c1 = new Criteria();
$c1->add(DomainsPeer::USERID,$UserID);
$update = new Criteria();
$update->add(DomainsPeer::SUSPENDED,$Suspended);
BasePeer::doUpdate($c1, $update, $con);
return true;
} catch(PropelException $e) {
return $e->getMessage();
}
}
I'm using Propel as my ORM. I've read through various unit testing topics that talk about creating 'Mocks' and 'Stubs' and what not but I have not been able to find anything that specifically tells you how to test a function like above.
My thinking goes something like: I need to test the function above so I would want to call it. But if I call it, it uses Propel as the ORM and according to the Unit Testing principles I should isolate each function by itself.
I just don't see a way to do that. What am I missing here?
I've found that mocking the ORM doesn't give me any confidence because the ORM configuration never gets tested. ORMs also have lots of action at a distance effects which can give false confidence with unit tests. Mocking the database driver or providing an alternate in-memory database gives me much higher confidence my code is correct and is about as hard as mocking the ORM.
SQLite is a great in-memory database for unit testing. It's on the PDO supported database list. (PDO is the Propel 1.3 database driver.) If you don't want to use an in-memory database, you might be able to find a PDO mock already written.
This is a generic answer in that I'm not familiar with Propel at all and only somewhat more familiar with PHP. The basic answer is that you use dependency injection. Instead of referring directly to your ORM, you create a wrapper around it, then inject the wrapper into your class/function to actually use. To do unit testing, then you create a mock or fake version of the wrapper that doesn't interface to the ORM but instead lets you configure the responses from the wrapper to your method invocations. This allows you to factor out the ORM when unit testing your functions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With