In PHP, `strtotime('tomorrow')` evaluates to the first midnight
after the current time.
Which means on Aug 14 at 23:59:59, strtotime('tomorrow') refers
to a timestamp merely 1 second in the future (Aug 15 00:00:00).
This causes the test to fail because this timestamp is computed
in a data provider, before the test itself starts. In order to
pass, it needs to be far enough in the future that it will also
be after the point in time where the test creates the page and
revisions in question.
Fix this by:
* ... moving it into the test itself, where even plain time()
should probably suffice, but that's for another time.
* ... using +24*3600 instead of strtotime().
Bug: T201976
Change-Id: Ice5d54af4fb7cffa8db9b657796ba6ebecdaffa0
The unit tests spend nearly half of their run time resetting the user table for
each test. But the majority of tests do not depend on the user table having the
exact value that the setup code resets it to, and do not need to modify the
user objects they require to run.
Fix that by providing an API for tests to get User objects, and to indicate
whether the User object will be subject to destructive modification or not.
This allows User objects to be reused across multiple unit tests.
Change-Id: I17ef1f519759c5e7796c259282afe730ef722e96
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
* New class ApiMergeHistory handles action=mergehistory
* Merge History functionality moved from SpecialMergeHistory to
MergeHistory
* SpecialMergeHistory now uses MergeHistory for actual merging
* Unit tests and i18n messages for above
Bug: T69742
Change-Id: Ic5078307dae78a2b3687e34a5d0a584988d483a1
