Every professional QA engineer knows that it is a great problem for automation tests (sometimes for manual as well, but there you have more flexibility and less formality) to use dynamic test data. When several times per month you have to tweak your tests that "suddenly" fail on CI due to some changes in the source of tests data.
I remember the project that is still fresh in my memory: we consumed data from the 3rd party service that provides data about autos. Once new model appears, 3-5 tests failed as number of models returned was changed, some validation rules were changed (another 10-15 tests were failed).
I know, that it could be a holly war around the approach of how to use test data. Some testers like to use mocked test data.
This exclude the usage of external service at all and makes their tests stable and predictable, but application logic isn't protected from the changes that appear on the side of external data provider.
Some guys will prefer the sandbox, that will exclude interaction with external service, but will tell our application that data comes from the service. But still
any change in the real API could affect an application logic (depending on logic, of course).
Dates posses the same problem.
Let's imagine that that your functionality under test verifies ranges of dates of birth.
If you are more then 18, you are allowed to open bank account, otherwise - no.
And usually we use some date, like 10-10-2003 (for the year 2020 this date shouldn't pass the validation) to
see how application will respond. In year 2020 this test will work, but next year it will produced false positive
result (if not adjusted) as people born in 2003rd, will be 18 in 2021.
Or, what is more tricky - is playing around boundary values for dates.
For example the 2002 year is valid for 18 years old
validation. But, customer's birthday could be somewhere in December (in December customer will turn 18). This means
that in May customer is still not eligible to open a bank account. And you have to check that. This means that
your tests start fail in December and they need to be adjusted.
I hope, that the problem is clear. Now...
There is several solutions of this problem, but I decided to go with the simplest (of course ) We need to have functionality the will produce date in agreed format based on the requirement and it should not be hardcoded in tests. We can pass necessary age and it should be converted to date. Let's go with the example above. You can pass 18 years to your method and it will always be converted to date when a customer is 18. And such functionality will always generate date that satisfies 18 years (in 2020, in 2021 or later).