Hacker News Reader

Comment by meric | Hacker News Reader

I don't use mocks much, except with regard to the "now" method. There's some code that relies on the current time, I can use mock to mock many values of 'current time' instead of being forced to only test the case where the current time is when I run the unit test. This is especially important when dealing with code involving time zone and day light savings.

View on HN

My experience with time is that whenever you build a system that is time-dependent in any meaningful way, you want to have "synthetic time" that you control, which you only feed with real time in a single, controllable place.

Otherwise you get nasty effects, such as time moving on while your system is processing etc.

I'm guessing you mean like:

    def has_expired(now=None):
        #.. implementation

instead of:

    def has_expired():
        #.. implementation

But at some point you need to call that method somewhere else...

    def get_request_handler(request):
        #...code
        now = timezone.now()
        if has_expired(now=now):
           raise Error403.

And `get_request_handler` still needs to be tested, which I 'stub' the API for getting the current time in the correct timezone within the test for the request. (Taking into account the other comment), using a library called 'mock'. (https://pypi.python.org/pypi/mock)

If you are only changing the value of what an API returns, that is not a mock. It is a stub.

I agree. But another option is to make all the methods that would call now() take an extra parameter of the current time. Talk about making your dependencies explicit...

But now you've...

a) changed your interface in a way that invites use cases you never intended (or wanted) to support.

b) added branching code anywhere that requires now()

Reply on news.ycombinator.com