You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: