The test scenario goes like this -

Change a value in config -> A job will execute at midnight -> config change will be update in system -> Verify that new config value is reflected.

Now how to wait for 24 hours for result verification. Any strategy for this kind of test cases


  • I'm confused. Is this a production system or a test system this all happens on? How much control do you have over the environment? Apr 25, 2019 at 14:12

3 Answers 3


Have the developers provide you with a way of triggering the scheduled task outside of its normal time slot.

Where I currently work this is provided as a webpage that has all of the possible scheduled tasks for a service, with buttons to trigger each one manually.

We use this page during our automated tests, and then observe the result.

We also do a manual check to make sure that the job itself has been scheduled correctly, e.g. it runs at midnight without being manually triggered.


I recommend the following approach:

  • Find the code that performs the overnight update.

  • Make sure it has good test coverage.

  • For the code that depends on it, replace the actual calls with mock responses.

  • For production ensure you have monitoring on the dependent service


When there is no way to trigger the job yourself like its proposed in https://sqa.stackexchange.com/a/38880/35888 you would need some kind of persistent memory. I could imaging a test making the change in the config and writing what was changed in a database (or plain file). A second test would read the database and only perform the necessary checks if there is an entry and enough time has passed

Though this feels like a dumb workaround and not like the "right" way to do it.

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.