Answers.Body: <p>Totten, who is a complete legend, shared this pearl with me:</p>
  
  <blockquote>
    <p>there are some examples like:
    <code>tests/phpunit/Civi/CCase/SequenceListenerTest.php</code>:    <code>\CRM_Utils_Time::setTime('2013-11-30 01:00:00');</code>
    however, these are the exception rather than the rule. there are lots of places where someone called <code>time()</code> or <code>strtotime()</code> without reading <code>CRM_Utils_Time</code> to find the baseline.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-27T12:16:09.823Z
Answers.Text: I assume that if you encountered such a case of time() or strtotime() being used then a core PR would be welcome?
Answers.UserDisplayName: ErichBSchulz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-31T15:41:24.257Z
Answers.Text: a) Yes, please, PR welcome!
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-31T15:43:12.190Z
Answers.Text: b) Ideally, time based actions are written with TDD in mind, and there's a testable function that allows you to pass in a time as an argument.  Of course, when we're talking about CiviMember code, that's wishful thinking at best.  But it's a good thought for the future.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-27T12:14:10.903Z
Answers.LastActivityDate: 2017-01-27T12:14:10.903Z
Answers.UserDisplayName: ErichBSchulz
Answers.Body: <p>You may not need to <em>wait</em> for a delayed action to occur. See if it is possible to test this without any delay.</p>
  
  <p>For example, <code>JobTest::testCallSendReminderLimitTo()</code> and some other scheduled reminder tests actually test a "scheduled" action, by creating the necessary circumstances to have it happen immediately.</p>
  
  <p>A (slow!) integration test might verify that a membership renewal is triggered at twelve months after join, while a group of unit tests might verify each component of that chain (one tests that the membership expiry is set as expected, another tests that the membership expiry rollover happens, another tests that the membership reminder is triggered at rollover).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-01-29T06:57:41.423Z
Answers.LastActivityDate: 2017-01-29T06:57:41.423Z
Answers.UserDisplayName: Chris Burgess
Body: <p>If I have an delayed action in my code then how on Earth can I unit test this?</p>
  
  <p>For example a membership transition?</p>
  
Tags: <php><unit-testing>
Title: How do I write unit tests for time based actions?
ThreadText: # How do I write unit tests for time based actions?
  
  (Asked by: username_0 on 2017-01-27)
  
  If I have an delayed action in my code then how on Earth can I unit test this?
  
  For example a membership transition?
  
  **Tags:** php, unit-testing
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2017-01-27. Score: 1
  
  Totten, who is a complete legend, shared this pearl with me:
  
  > there are some examples like:
  > `tests/phpunit/Civi/CCase/SequenceListenerTest.php`: `\CRM_Utils_Time::setTime('2013-11-30 01:00:00');`
  > however, these are the exception rather than the rule. there are lots of places where someone called `time()` or `strtotime()` without reading `CRM_Utils_Time` to find the baseline.
  
  > **Comments:**
  > **username_0**: I assume that if you encountered such a case of time() or strtotime() being used then a core PR would be welcome?  
  > **username_1**: a) Yes, please, PR welcome!  
  > **username_1**: b) Ideally, time based actions are written with TDD in mind, and there's a testable function that allows you to pass in a time as an argument.  Of course, when we're talking about CiviMember code, that's wishful thinking at best.  But it's a good thought for the future.  
  
  ---
  
  ### Answer by username_2 on 2017-01-29. Score: 0
  
  You may not need to *wait* for a delayed action to occur. See if it is possible to test this without any delay.
  
  For example, `JobTest::testCallSendReminderLimitTo()` and some other scheduled reminder tests actually test a "scheduled" action, by creating the necessary circumstances to have it happen immediately.
  
  A (slow!) integration test might verify that a membership renewal is triggered at twelve months after join, while a group of unit tests might verify each component of that chain (one tests that the membership expiry is set as expected, another tests that the membership expiry rollover happens, another tests that the membership reminder is triggered at rollover).
  
  
  ---
  
  