My service has long running processes. For example - user can signup, but if email not verified after 7 days, we send a reminder email.

I need my system test to cover this scenario as well.

Currently, I manipulate the data in the DB so the system thinks the user signed up a week ago.

But this makes my tests tightly coupled with the model and the code itself and the developers.

Is there a better way to handle this?

  • 3
    Time travel. Figure out how your system knows what time it is and take control of that. – candied_orange Aug 14 '18 at 3:40

First, a time value like "7 days" should be a configuration parameter of your process, not something hardcoded or something the process can exclusively retrieve from the database. When you implement the system like that, your system test can replace "7 days" by something like "7 seconds", which should solve your problem.

The other approach I see is to make the clock an abstraction which can be passed as an interface into the process, so you can mock out the "real" clock by a mocked version for testing purposes.

  • Definitely agreeing that the time value should be configured, but depending on the precision needed, "7 days" might present a whole bunch of problems that "7 seconds" doesn't (e.g., if the 7 days period happens across the end of the month, does it work properly?). It might not be a huge concern if you're not writing your own time managing code (please don't if it's not really necessary. Dealing with time is complex), but I thought it should be mentioned. – Iker Aug 14 '18 at 8:40
  • @Iker: I see where you are coming from, but in most environments today, I would expect to have a standard date/time datatype available which makes it quite unnecessary to deal with things like "month overflows", and also allowing to implement the logic in a time scale agnostic manner. If that's not the case, there should be tests specificially designed for testing an overflow, and such tests can be implemented with seconds instead of days as well. – Doc Brown Aug 14 '18 at 9:34
  • It's definitely preferable, and the recommendation is that, if you do have a datatype that handles times, 110% use that. Even if it's a library that does the date handling for you and not a datatype, again 110% use that. In my experience so far (and I'm aware that I might just be an outlayer), that's much less common than I'd have liked it to be. – Iker Aug 14 '18 at 9:53
  • Unfortunately this system does not have a configuration, and all the time based algorithms are by days.. Time skipping might affect other system tests. I think I need to have a 2 steps solution - move everything to configuration, then override the configuration for the tests. Alternatively, I'll try to separate the build to X different steps (depending on how many time jumps I need). So step 1 would be "prepare data", then step 2 would be "after X days" etc.. Lets see how it goes. – guy mograbi Aug 14 '18 at 16:11
  • 2
    @guymograbi: it is an old wisdom that for testing a system, it is sometimes necessary to make it more testable first, which may involve changing it ;-) This can actually mean to add "maintenance hatches". – Doc Brown Aug 14 '18 at 16:17

Time skipping might affect other system tests

That rules out a lot of tools, but timecop might help you by accelerating time without skipping (disclaimer- I have never used it myself)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.