Simulating the passing of time in unittesting

Question

I've built a paywalled CMS + invoicing system for a client and I need to get more stringent with my testing.

I keep all my data in a Django ORM and have a bunch of Celery tasks that run at different intervals that makes sure that new invoices and invoice reminders get sent and cuts of access when users don't pay their invoices.

For example I'd like to be a able to run a test that:

1. Creates a new user and generates an invoice for X days of access to the site

2. Simulates the passing of X + 1 days, and runs all the tasks I've got set up in Celery.

3. Checks that a new invoice for an other X days has been issued to the user.

The KISS approach I've come up with so far is to do all the testing on a separate machine and actually manipulate the date/time at the OS-level. So the testing script would:

1. Set the system date to day 1

2. Create a new user and generate the first invoice for X days of access

3. Advance then system date 1 day. Run all my celery tasks. Repeat until X + 1 days have "passed"

4. Check that a new invoice has been issued

It's a bit clunky but I think it might work. Any other ideas on how to get it done?

Answer 1

You can use mock to change the return value of the function you use to get the time (datetime.datetime.now for example).

There are various ways to do so (see the mock documentation), but here is one :

import unittest
import datetime
from mock import patch

class SomeTestCase(unittest.TestCase):
    def setUp(self):
        self.time = datetime.datetime(2012, 5, 18)
        class fakedatetime(datetime.datetime):
            @classmethod
            def now(cls):
                return self.time
        patcher = patch('datetime.datetime', fakedatetime)
        self.addCleanup(patcher.stop)
        patcher.start()

    def test_something(self):
        self.assertEqual(datetime.datetime.now(), datetime.datetime(2012, 5, 18))
        self.time = datetime.datetime(2012, 5, 20)
        self.assertEqual(datetime.datetime.now(), datetime.datetime(2012, 5, 20))

Because we can't replace directly datetime.datetime.now, we create a fake datetime class that does everything the same way, except returning a constant value when now is called.

Answer 2

Without the use of a special mock library, I propose to prepare the code for being in mock-up-mode (probably by a global variable). In mock-up-mode instead of calling the normal time-function (like time.time() or whatever) you could call a mock-up time-function which returns whatever you need in your special case.

I would vote down for changing the system time. That does not seem like a unit test but rather like a functional test as it cannot be done in parallel to anything else on that machine.