Php – Unit Testing and 3rd party packages. Do I mock or not

PHPtddtestingunit testing

I'm just getting used to unit testing and on my new project I decided to adopt a TDD approach.

My code below is to test the UserServices class which is responsible for creating a user, deleting a user, checking if a user exists etc.

Am I on the right lines? I ask because everywhere I look it discusses mocking and I can't help but think I should be mocking predis (a package used for interacting with Redis in PHP). But, mocking it would be difficult as my class expects an instance of Predis.

In the setup I create a dummy user to perform actions on. I may need to create more than one, but at this stage I just use the one. Although, there are methods such as createUser that would need to create an entirely new user.

<?php

namespace VoteMySnap\Tests;

class UserServicesTest extends \PHPUnit_Framework_TestCase
{
    const HOST = '127.0.0.1';
    const PORT = 6379
    const AUTH = NULL;

    public $predis;

    public function setUp()
    {
        $this->predis = new \PredisClient([
            'host' => HOST,
            'port' => PORT
        ]);

        /*
         * Create a dummy user
         */
        $dummyUser = [
            'user:1' => [
                'snapchat_username' => 'james16',
                'password' => 'somesecret',
                'email' => 'test@example.com'
            ]
        ];

       /*
        * Insert user into Redis
        */ 
        $this->predis->hmSet(key($dummyUser), $dummyUser[key($dummyUser)]);
    }

    public function tearDown()
    {
        /*
         * Remove the dummy user
         */
        $this->predis->delete(key($dummyUser));
    }  
}

Am I on the right tracks here?

Best Answer

I have always followed the maxim that a unit test tests one thing and only one thing. Programming such that each method does one thing and one thing only, should mean you can write a unit test for that method fairly easily.

If your method calls out to any other services or classes, then you should mock those so their behavior during the test is completely known. PHPUnit allows you to mock classes including those in packages you are using, eg PredisClient. You would want to also mock the hmSet method. I would recommend reading the following to gain a better understanding of how PHPUnit does this.

https://phpunit.de/manual/current/en/test-doubles.html

You may also want to refactor your code to instantiate PredisClient outside of the class you are testing (if you don't already) and then inject it via constructor parameter as this allows your mocked version to be easily injected. Search for Dependency Injection to see how this can help!

Related Solutions

Real-Time Unit Testing – How to Implement Mocking

I'm going to use Python-like pseudocode based around your test cases to (hopefully) help explain this answer a little, rather than just expositing. But in short: This answer is basically just an example of small, single-function-level dependency injection / dependency inversion, instead of applying the principle to an entire class/object.

Right now, it sounds like your tests are structured as such:

def test_3_minute_confirm():
    req = make_request()
    sleep(3 * 60)  # Baaaad
    assertTrue(confirm_request(req))

With implementations something along the lines of:

def make_request():
    return { 'request_time': datetime.now(), }

def confirm_request(req):
    return req['request_time'] >= (datetime.now() - timedelta(minutes=5))

Instead, try forgetting about "now" and tell both functions what time to use. If it's most of the time going to be "now", you can do one of two main things to keep the calling code simple:

Make time an optional argument that defaults to "now". In Python (and PHP, now that I reread the question) this is simple - default "time" to None (null in PHP) and set it to "now" if no value was given.
In other languages without default arguments (or in PHP if it becomes unwieldy), it might be easier to pull the guts of the functions out into a helper that does get tested.

For example, the two functions above rewritten in the second version might look like this:

def make_request():
    return make_request_at(datetime.now())

def make_request_at(when):
    return { 'request_time': when, }

def confirm_request(req):
    return confirm_request_at(req, datetime.now())

def confirm_request_at(req, check_time):
    return req['request_time'] >= (check_time - timedelta(minutes=5))

This way, existing parts of the code don't need to be modified to pass in "now", while the parts you actually want to test can be tested much more easily:

def test_3_minute_confirm():
    current_time = datetime.now()
    later_time = current_time + timedelta(minutes=3)

    req = make_request_at(current_time)
    assertTrue(confirm_request_at(req, later_time))

It also creates additional flexibility in the future, so less needs to change if the important parts need to be reused. For two examples that pop into mind: A queue where requests might need to be created moments too late but still use the correct time, or confirmations have to happen to past requests as part of data sanity checks.

Technically, thinking ahead like this might violate YAGNI, but we're not actually building for those theoretical cases - this change would just be for easier testing, that just happens to support those theoretical cases.

Is there any reason you would recommend one of these solutions over another?

Personally, I try to avoid any sort of mocking as much as possible, and prefer pure functions as above. This way, the code being tested is identical to the code being run outside of tests, instead of having important parts replaced with mocks.

We've had one or two regressions that no one noticed for a good month because that particular part of the code was not often tested in development (we weren't actively working on it), was released slightly broken (so there were no bug reports), and the mocks used were hiding a bug in the interaction between helper functions. A few slight modifications so mocks weren't necessary and a whole lot more could be easily tested, including fixing the tests around that regression.

Change the system date and time for the test, using exec(). This can work out if you are not afraid to mess up with other things on the server.

This is the one that should be avoided at all costs for unit testing. There's really no way of knowing what kinds of inconsistencies or race conditions might be introduced to cause intermittent failures (for unrelated applications, or co-workers on the same development box), and a failed/errored test might not set the clock back correctly.

Unit Testing – Unit Testing with External Packages or Assemblies

Mock the externals for your unittests, where applicable

It all depends on what the external library does for you. For example, if you have a class that depends on an external library that works with the file system you probably want to mock that and not perform any actual filesystem operations in your unittest. If you have an external library that does mapping from one object onto another, you'll probably be fine and would want to use that external library in your unittests directly.

Remember that unittests are about a cohesive unit of code, not a single class.

Have broad integrationtests that cover your external library

If you have external libraries, make sure that your integrationtests cover some cases for them. You want to test your integration with those external libraries as part of your tests.

Contribute to the package if it lacks tests

If you find that the external library you are using lacks tests, do not write those tests in your application. Instead, see if you can write the code and submit it to the maintainer and get it in the official version so others can benefit from it too.

Best Answer

Related Solutions

Real-Time Unit Testing – How to Implement Mocking

Unit Testing – Unit Testing with External Packages or Assemblies

Related Topic