Designing For Time Travel
The Need To "Time Travel" In Software Testing
Some software functionality is specific to date/time i.e. functions differently according to the current date/time.
For example, it might be valid to book a ticket before an event but invalid after the event has occurred and therefore event booking software would need to validate bookings based on the current date/time each time a booking is made for an event.
As we want to test all aspects of functionality in advance of shipping our software, we need a means to change the current date/time during testing so that we can test before and after scenarios. We refer to this dynamic date-time test capability as "time travel".
Implementing Time Travel
If "time travel" was not designed into your software product from the start of your project then you may well have to re-engineer your existing software to enable it. Depending on the complexity of your product this may not be a trivial task.
"Time travel" is typically implemented by encapsulating the mechanism by which an application accesses the current date/time and the way in which date/time information is encoded into, or derived from, application data. Such functionality might be implemented in a common library shared by all your application components.
Application configuration settings can be used to determine whether an application should use the real system date/time or whether an adjustment should be applied or if a different date/time should be used instead.
Things Which Hinder Time Travel
Anything falling outside the boundaries of your application will not honour your "time travel" configuration. This may be things such as file system timestamps, external data sources or messages from interfacing systems.
Database inserts/updates that apply date/time information to records via queries based on the database server date/time may also hinder your "time travel". You may choose to design around this by allowing only your application to set timestamp values and not the database itself.
However, use of a consistent coding pattern for date/time handling, combined with a configurable offset used to adjust all date/time values accordingly, can help overcome the above problems.
Holding date/times in inconsistent locales or storage formats is not such an easy problem to overcome and really should be corrected.
Lack of code reviews and consistent coding standards enforcement around how code handles date/time information will also likely hinder your "time travel" capability.
Regression Testing
The ability to change the "time travel" configuration settings on the fly during an automated regression test without the need to stop or re-start application components is extremely helpful as this allows many different scenarios to be tested as part of a single regression test. You may need to change how your application accesses configurations settings in order to achieve this but the effort will be worth it.
Happy time travelling!
Thank you for liking this page.
Tim Simpson
9th February, 2021
#LifeAtCapgemini