It has never occurred to me before but today I suddenly realized that:

  • If a data is able to be kept for a long period of time, how do we test it using test automation?

Say, a given data is to be kept for 100 days. We need to test it

We are expected have 100 days in scenario, no one is pushing us to deliver test result within 100 days.

  • We cannot simply read this data on day 1 and again on day 100, as there is no guarantee that this data has not been changed between day 1 and day 100.
  • Another extreme will be we read this data frequently enough for 100 days in a row. But it does not sound very efficient.

Any ideas?

  • 1
    "Say, a given data is to be kept for 100 days". What does it mean exactly? In 100 days it should be removed? Or there is a guarantee that it will persist for at least 100 days? It also makes sense to consider how does your system account the "age" of your data. It either uses internal timer, or a system time or something else.
    – Alexey R.
    Commented Feb 8, 2018 at 9:29
  • @AlexeyR., good point, my question was a bit too generic.
    – Yu Zhang
    Commented Feb 8, 2018 at 18:03
  • Alexey ,it means like an price Alert which may auto expire and delete from the system after N days. Commented Feb 9, 2018 at 10:14

2 Answers 2


You didn't supply enough details about what the system does and what are expected results for the data, but you might be able to use utilities to accelerate time, for example timecop

  • timecop is it. That is exactly what I was looking for.
    – Yu Zhang
    Commented Feb 8, 2018 at 18:12

It depends. As others have said, you didn't supply much in the way of details, such as what sort of testing you're doing, where/how the data is managed, and how sure you want to be.

So, with that said, at a function test level, you could have a scaffolding setup. Create a generation of data, set the clock ahead 100 days (probably by intercepting the datetime() call of the system under test) and make sure that the file is deleted.

If it's data integrity you're concerned about, though, I'd suggest approaching that from a system level, not just a test level. Specifically, I'd suggest checksumming the data, because the system under test isn't the only possible source of corruption.

  • thanks, checksumming is a good idea too, I will combine it with Rsf's answer.
    – Yu Zhang
    Commented Feb 8, 2018 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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