Got into your channel via your cyberpunk video as Im sure many other will have done, could I suggest in addition to the mailing list you set up a discord server for those of us struggling with the thorny issues of transformation to CI/CD from deep legacy
My concern about the time travel against a running system (it makes absolutely perfect sense for unit tests) is that it opens up a route to change the time from outside of the system. We could add logic to only open it for test and dev environments but then we'd need a test in prod to make sure it was disabled. The way I've dealt with this in the past is to add the time element as a config item, e.g. OVERDUE_AFTER, and deploy a specific version of the SUT with this set to a low value. It's not ideal but it feels safer to me. Especially as the logic will have been tested thoroughly at unit test level.
What I have seen that has been successful is to program to an ITime interface. Implement the interface twice. Once with a real-time clock. And once with a clock that you can set the time of. During tests, inject your test implementation of ITime. During runtime inject the real-time implementation.
I can't imagine a language where you couldn't do this. Your TimeProvider is just another name for my "Clock", this doesn't have to be a class, it could be a function, a module, or even by intercepting a "GOTO" call in assembler. So unless your language is not a general purpose programming language, I am pretty sure that you will be able to do this.
Got into your channel via your cyberpunk video as Im sure many other will have done, could I suggest in addition to the mailing list you set up a discord server for those of us struggling with the thorny issues of transformation to CI/CD from deep legacy
Agreed, a Discord server might be nice.
That’s be awesome!!
I totally agree with you, but isn't slack much better than discord for this?
Agree. In Java I never execute Instant.now() or similar methods. Better create java.time.Clock object, inject it and execute Instant.now(clock)
My concern about the time travel against a running system (it makes absolutely perfect sense for unit tests) is that it opens up a route to change the time from outside of the system. We could add logic to only open it for test and dev environments but then we'd need a test in prod to make sure it was disabled.
The way I've dealt with this in the past is to add the time element as a config item, e.g. OVERDUE_AFTER, and deploy a specific version of the SUT with this set to a low value. It's not ideal but it feels safer to me. Especially as the logic will have been tested thoroughly at unit test level.
What I have seen that has been successful is to program to an ITime interface. Implement the interface twice. Once with a real-time clock. And once with a clock that you can set the time of.
During tests, inject your test implementation of ITime. During runtime inject the real-time implementation.
In languages that can't replace inputs like that, would you think is valid to inject a "TimeProvider" that we could double in test to control time?
I can't imagine a language where you couldn't do this. Your TimeProvider is just another name for my "Clock", this doesn't have to be a class, it could be a function, a module, or even by intercepting a "GOTO" call in assembler. So unless your language is not a general purpose programming language, I am pretty sure that you will be able to do this.