Timer

[bdemann]

• [ ] clear_timer
• [ ] set_timer_interval
• [ ] set_timer

[bdemann]

Let's take a minute to think about what kind of things we would test in a property test for timer

• Feasibility of Property Tests for Delay Duration

  • How feasible is it to write property tests that account for all possible delay values?
  • Edge cases, like a delay close to u64::MAX, present a major challenge since a maximum delay would not trigger until the year 2554.
  • This suggests that we may need to set a more practical upper limit for testing delays, though this limit could miss some edge cases by design.
  • Is there actual value in testing an arbitrary range from 0 to u64::MAX - time()?
  • Property tests often explore a wide range of values, but with timers, testing such an extensive range may be impractical and provide limited insights.
  • A more efficient range might allow us to focus on specific, manageable edge cases, but even then, the range's utility for meaningful tests is unclear.

• Arbitrary Callback Functions in Property Tests

  • How useful or feasible is it to include arbitrary callback functions in these tests?
  • Right now, a callback might just set an arbitrary value, which feels limited and may not truly stress-test the function's behavior.
  • Would this type of callback testing actually give us meaningful insights into how setTimer or setTimerInterval handles more complex or varied callbacks?
  • Would an "arbitrary function generator" make sense?
  • If we tried to generate random functions, what kinds of functions would we even include? How would we verify correct execution in property tests?
  • The time and complexity involved in building and validating such a generator may far outweigh the potential value, especially if these tests provide little additional assurance.

So completely arbitrary timers lengths and callbacks seem a little unreasonable to me, but maybe we can come up with some properties to test that don't require us to do all of that