How do you do Unit Testing With an App that Uses an ORM?

Question

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?

G-Man

Answer 1

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.

Answer 2

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.

Answer 3

I've been reading Misko Hevery's blog about testing a lot lately. It covers this situation; you'd need to use DI (dependency injection).

I am struggling myself with this a bit as well, and I also use propel.

For one, you could move the "suspend" method to the "Object" class rather than the peer. For this particular function anyway, you don't need to use the static methods to achieve this. Your API could look like:

MyObjectPeer::retrieveByPK(1)->suspend();

This would be testable via normal unit testing methods.

If it's really the database that needs to be tested, then AFAIK you need to actually have the DB involved in the test. I am using ltree and postgis a lot in my current project and I can't think of any other way to run unit tests for the model logic that depends on the DB other than to include it in my tests.