[Development] date/time adjust for (auto) testing

[André Somers]

Curtis Mitch schreef op 3-6-2015 om 10:00:
>> -----Original Message-----
>> From: development-bounces+mitch.curtis=theqtcompany.com at qt-project.org
>> [mailto:development-bounces+mitch.curtis=theqtcompany.com at qt-project.org]
>> On Behalf Of André Somers
>> Sent: Wednesday, 3 June 2015 8:39 AM
>> To: <development at qt-project.org>
>> Subject: [Development] date/time adjust for (auto) testing
>>
>> Hi,
>>
>> We have applications that use the current date and time at places spread
>> around the code. For normal operations, that works very nicely. However,
>> we find that for (auto) testing, it would be very convenient if we could
>> trick the application into believing it is some other date/time, so that
>> we can test if certain behaviours work the way we would like to
>> automatically. Currently, these tests take a lot of time because we
>> actually need to manually adjust the system date and time, do some
>> stuff, then adjust again, etc.
>>
>> It would be really confortable if there was some control to set a
>> date/time offset (so the time keeps running) or a fixed date/time to be
>> returned from currentDate(), currentTime() or currentDateTime()
>> respectively. I guess access to such a thing does not belong in the main
>> Qt classes, but is really a testing tool, so perhaps it could find
>> refuge in QtTest somewhere. Would a contribution adding such a thing
>> stand any chance of being accepted, or would this be considered out of
>> scope or even unwanted?
>>
>> An alternative might be to hook the windows kernel API, but that may be
>> much tricker to get right and may have unforseen consequences for the
>> code injected by Squish doing the actual testing.
>>
>> André
>>
>> --
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> Sounds like a great thing to have if you can get it working. The QDateTime tests themselves would benefit from this quite a lot.
>
> Perhaps you've already seen, but it looks like Thiago attempted something similar with a8c74ddcf78604c9038ba2a2bea81e445e4b3c58:
>
> http://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp#n2988
>
>
I did not see that yet. What I have in mind is not actually changing the 
system date/time/timezone, but changing what Qt returns for it to ease 
(regressino) testing.

A concrete use case:
We have a database with entries on a specific dates. We also have an 
export operation that allows you to specify a time period to export, 
with some default ranges defined: "today", "this week", "this month". 
Obviously, that uses the current date and time. But that hinders 
testing, as an automatic test would preferably use a pre-made database 
that we just prepare once and then just run the test on. Running the 
test next week will yield different results from running the test this 
week, and that is hard to evaluate. On the other hand, creating a new 
database for the test is tricky, as records get their time stamp 
automatically from, again, the current date and time. So creating a new 
record that appears one month and a day old is just as tricky. We'd like 
to avoid creating special paths in the actual application code as much 
as we can, because that increases maintenance costs and diminishes the 
value of the actual test: we'd be testing a special code path no actual 
user will ever use.

If we were able to manipulate the 'current' time and date returned by 
Qt's date/time classes, testing this would be easy. We'd just have the 
test script set a pre-defined 'current' date, and be able to auto-test 
everything against a pre-defined database. I would add something to the 
actual code of the current functions to adjust the result when such an 
adjustment is set. That would incur a small overhead in the actual 
function, even if not enabled I think.

André