[TYPO3-core] RFC #13192: Feature: Allow different timestamp as optional parameter in constructor of class tx_scheduler_croncmd

[Christian Kuhn]

Hey Benni,

Benjamin Mack wrote:
> according to the comment, it should always be in the future. So we could
> do a check against time() to see if $tstamp is really in the future?

No, it's up to the user to feed it with a correct timestamp in this
case. The timestamp must be in the future for the scheduler logic around
it only, it's not important for this class itself.

Main use case of this parameter is to allow static answers for unit
tests. If I'm unable to give an own initialization date to this class
I'd need to do one of the following, imagine I want to test if the class
calculates every Monday of a month (* * * * 1).

- If the tests use the public interface and it's now 29.1.2010, my test
would have to calculate all pending mondays of this month on it's own
(which are none in this case), call the class and compare the values.
- The test could require_once() the class, write an own class which
extends it, add public wrapper methods to the protected methods,
enabling the tests to call the procected logic methods directly (which
accept different timestamps again).

Both options are ugly, error prone and lead to complex tests, I'd prefer
proposed solution, see #13193 how tests could actually look like.

Regards
Christian