Fix for #99 -- if no time to be frozen is available use the real datetime

[mindojo-victor]

No description provided.

[coveralls]

Coverage increased (+0.02%) to 96.793% when pulling 9714f9d on mindojo-victor:master into a6653a3 on spulec:master.

[spulec]

Is this necessary? Should we ever be calling _time_to_freeze if there isn't cls.times_to_freeze?

[mindojo-victor]

Should we ever be calling _time_to_freeze if there isn't cls.times_to_freeze?

You mean to check if cls.times_to_freeze is empty in each place where we call _time_to_freeze?

[spulec]

I'm trying to figure out the scenario in which this happens. Do you have a test to reproduce the issue?

[mindojo-victor]

I don't have the reproducible tests. It happens sometimes. Looks like it depends on test sequence. Some tests patch the datetime module, then next test_* is module is run, but the decorator is already finished. I am using nose2.

If I were to decide what to do with this, I would not try to restore original datetime module. Just leave the module patched: if there is a frozen datetime to return, return it, otherwise return pass through to the original datetime. This would make the implementation much simpler.

[spulec]

thanks!

[AndreasBackx]

@spulec could a new release be published to Pypi that includes this and the other new changes? We're currently using the latest commit for testing because of this bug.

[spulec]

Version 0.3.9 is now released!