3 ms·
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 'curren
by meric 12y ago
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.
- mpweiher 12y agoMy 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.
- meric 12y agoI'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 https://pypi.python.org/pypi/mock)
- nahname 12y agoIf you are only changing the value of what an API returns, that is not a mock. It is a stub.
- blt 12y agoI 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...
- GrinningFool 12y agoBut 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()