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?

Answer 1

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 2

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 3

I was trying to tackle the same problem while building a PHPUnit plugin for Symfony. I ended up approaching it similarly to Django's test framework — use a separate database/connection, and destroy and rebuild it before every test.

I found that I was also able to get away with only rebuilding the test database before the first test in a test run (or if a test explicitly instructs it to); before the other tests, it just deletes all data to speed things up a little.

Answer 4

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.

Answer 5

This is an exemple of a class with hard dependency which can't be unit testable.

We could be able to test with a connection to another database but then, it's not a Unit Test anymore but an Integration Test.

The better alternative that I think about is to have an QueryFactory class that will wrap all the different methods that you need and then, you will be able to mock it.

First in first I create an interface

interface iQueryFactory
{
    function firstFunction($argument);
    function secondFunction($argument, $argument2);
}

The QueryFactory with all your ORM request we need

class QueryFactory implements iQueryFactory
{
    function firstFunction($argument) 
    {
        // ORM thing
    }

    function secondFunction($argument, $argument2)
    {
        // ORM stuff
    }
}

There is the business logique with the injection of the query factory

class BusinessLogic 
{
    protected $queryFactory;

    function __construct($queryFactoryInjection) 
    {
        $this->queryFactory= $queryFactoryInjection;
    }

    function yourFunctionInYourBusinessLogique($argument, $argument2) 
    {
        // business logique

        try {
            $this->queryFactory->secondFunction($argument, $argument2);
        } catch (\Exception $e) {
            // log
            // return thing
        }

        // return stuff
    }
}

The mock part, note that I don't use a mock framework for my exemple (btw you can create a response setter)

class QueryFactoryMock implements iQueryFactory
{
    function firstFunction($argument) 
    {
        if (is_null($argument)) 
        {
            throw new \Exception("");
        } 
        else 
        {
            return "succes";
        }
    }

    function firstFunction($argument, $argument2) 
    { 
        // sutff  
    }
}

Then finally the Unit Tests who test our business logic with the mock implementation

class BusinessLogicTest extends PHPUnit_Framework_TestCase 
{
    public function setUp() 
    {
        require_once "BusinessLogic.php";
    }

    public function testFirstFunction_WhenInsertGoodName() 
    {
        $queryMockup = new QueryFactoryMock();
        $businessLogicObject = new BusinessLogic($queryMockup);
        $response = $businessLogicObject ->firstFunction("fabien");

        $this->assertEquals($response, "succes");
    }

    public function testFirstFunction_WhenInsetNull() 
    {
        $queryMockup = new QueryFactoryMock();
        $businessLogicObject = new BusinessLogic($queryMockup);
        $response = $businessLogicObject->firstFunction(null);

        $this->assertEquals($response, "fail");
    }
}