Add testcases for time window filter cache entry #445
Conversation
|
The test doesn't appear to be validating what it intends to. Ensuring something is in the cache does not check whether the filter calculates the window again or not. |
|
@jimmyca15 In the latest commit, I added an internal property for the timewindow filter to track how many times recurring time window is re-calculated. What do you think? |
|
This PR goes after PR #452 |
@zhiyuanliang-ms too invasive. Can we pass a custom implementation of IMemoryCache and check whenever memorycache.Set is called? |
…-Dotnet into zhiyuanliang/update-timewindow-filter-cache-test
@jimmyca15 Updated in 5da2d7d |
|
@rossgrambo Can you approve this PR? |
| mockedTimeProvider.UtcNow = mockedTimeProvider.UtcNow.AddHours(1); | ||
| Assert.True(await mockedTimeWindowFilter.EvaluateAsync(context)); | ||
| } | ||
| mockedTimeProvider.UtcNow = DateTimeOffset.Parse("2024-2-2T23:00:00+08:00"); |
There was a problem hiding this comment.
It might make these tests more readable if we switched this out for "StartTimeStamp.PlusDays(1)" or something similar. Not sure if it would lead to issues.
There was a problem hiding this comment.
I find it easier to see the date directly, I used to open a calendar and check whether a date hits a recurrence. With"StartTimeStamp.PlusDays(1)", I need to do some extra calculation in my mind.
Why this PR?
Added testcases to check whether the cache of time window filter cached the correct closest active recurring time window start.
#266 (comment)