Timeline for Simulating different times of day when running integration tests, .NET/XUnit
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 17 at 17:19 | comment | added | Ewan | I think this is a misconception, it's not just about scheduling : "...Wednesday it should perform certain operations on data pertaining to dates that precede the previous Wednesday. On other days of the week the process behaves differently.." | |
| Apr 16 at 22:54 | comment | added | Arseni Mourzenko | I don't understand why would the code need to know the “previous Wednesday.” In the original question, the distinction between Wednesday and other days was used merely to know if the task should run or not. That's all. If you need to run it manually on the next day, then changing the condition is the solution; no need to pretend that it's a different day than it is. | |
| Apr 16 at 12:47 | comment | added | Ewan | It seems like you are avoiding the issue by adding parameters. but unless you pass a date you are always going to fall fowl of lack of information. eg. ive been run by an admin and its not wednesday, but which is the "previous wednesday" I need to use? In any case you need two dates. The current date, for logging etc, and the date the function should operate on | |
| Apr 16 at 12:39 | comment | added | Arseni Mourzenko | You handle it by modifying the run condition accordingly. That is, instead of “continue if today is Wednesday,” the condition could read: “continue if today is Wednesday or I'm called by a supervisor who knows what he's doing.” This way, your code matches reality. By comparison, think of all the consequences if you lie to your code by pretending it's Wednesday when it's Thursday—imagine for example debugging a case where the code clearly says that it won't run on Thursday, but the logs show it actually ran on Thursday... | |
| Apr 16 at 11:02 | comment | added | Ewan | maybe you could explain how you handle that scenario with an injected time provider. ie I want to run wednesdays logic, but my audit log should still say it ran of thursday | |
| Apr 16 at 10:19 | comment | added | Arseni Mourzenko | @Ewan: Absolutely not the same. In .NET, DI is usually handled by a DI library, with minimal impact on the interface. As to how to rerun failed tasks, I don't see how this is relevant here, and it may be indicative of wrong design anyway—I highlighted it already in my answer. In all cases, you shouldn't pretend it's Wednesday on Thursday just to run a task that failed the previous day—this is too messy and is clearly a terrible design. | |
| Apr 16 at 9:19 | history | edited | Ewan | CC BY-SA 4.0 |
added 897 characters in body
|
| Apr 16 at 9:14 | history | edited | Ewan | CC BY-SA 4.0 |
added 897 characters in body
|
| Apr 16 at 9:01 | comment | added | Ewan | Injecting a time provider is the same as passing a parameter, but needlessly clutters your code and makes thing like what steve is suggesting harder. how do you rerun some fails tasks with time they should have run at, whilst also logging the time they re-ran at? | |
| Apr 15 at 23:27 | comment | added | Steve Jessop |
There other reasons why it can be a good idea to accept the nominal time as a parameter though. For example to run an atomic set of operations as if they all happened at a single instant, which you can then identify as the instant the whole thing happened, and they all have consistent cache expiries, and the same timestamp in the database, and whatnot. But then, logically that won't be the current time, any more than you think of the time passed to touch -d as the "current" time. It's the time you're setting something to. Testability then is a bonus, not the sole reason for doing it.
|
|
| Apr 15 at 22:43 | comment | added | Arseni Mourzenko | No, no, no! Moving the date time to a parameter would only move the problem up the stack and clutter unnecessarily the interface. It makes little sense for a method that should check if a task should run right now based on the current time to request the current time to the caller. Instead, DI is your friend, and .NET finally made it easy now to inject a time provider into classes that rely on time. | |
| Apr 15 at 14:56 | history | answered | Ewan | CC BY-SA 4.0 |