-
Notifications
You must be signed in to change notification settings - Fork 124
Description
The TimeWindowFilter has a property to allow for providing the TimeProvider to the filter. However, this property is currently internal which does not allow it to be used beyond the unit testing of the filter (or other internal use cases). Whilst one of the primary purposes of the TimeProvider is to allow for mocking date times during unit testing there are also other use cases for use of TimeProvider such as when custom TimeProvider implementations are used in a running application. So, it would be useful to allow the TimeProvider implementation to be passed to TimeWindowFilter by consuming applications of the library.
As an example of a use case, in the lower environments of our applications (everything but production) we allow users to set / override the current date and time. This allows testers to be able to test date time dependent functionality more easily as in cases where they would normally need to wait an amount of time for something to occur they can instead just advance the date to the date required to test that the system then performs the functionality correctly (whatever that functionality may be). We also often use the TimeWindowFilter to ensure features are enabled on a certain date but the testers can't test that a feature gets enabled on a specific future date. If the TimeWindowFilter allowed passing a custom TimeProvider then it would allow for this testing.
As a workaround for this, we have implemented our own version of the TimeWindowFilter that is basically an exact copy but allows the TimeProvider to be passed to the filter. This works but if the built in TimeWindowFilter was updated to allow passing TimeProvider we could then remove our own copy and avoid the basically identical duplicate.