You don't want to change the system date. Too many other things depend on the date.
What you want to do is create a test helper that intercepts the application's call to the system date/time and returns the value you set. Exactly how you do this will depend on the language and framework you're using.
With Microsoft's test framework you'd define a shim to intercept any calls to DateTime.Now(), so that when your test ran, instead of using the system date you'd be using the date you set (the link includes an example with an application that calls to a property of DateTime.Now() ).
Depending on the nature of the application you're testing, the framework it uses, and the language and tools you're using, you may have to search for a different way to fake out the application's date/day recognition.
Another option is to call the system's Now() routine yourself, then check that the application is behaving correctly for the current day. This is more complex but it can still work.
Option 3 involves data manipulation: if the application you're testing stores its open/closed days of the week in a database you control, change them to fit the test you want to run and then restart the application. If you want to check that it displays closed when it's outside hours, you set the store operating hours so that the store closed some set amount of time before the current system date/time, and will open some set amount of time after the current system date/time.
Reasons NOT to change the system date:
- It can wreak utter havoc on your test reporting.
- And your test logs. Especially if you're running remotely (your run-system will report one time, and the captures from the application and its logs will report something completely different).
- A system date that is too far from the actual date can cause major problems with networked applications and systems. Depending on the networking protocol, you may not be able to access the system with the changed date.
- This can make databases on a different server unreachable.
- If the application depends on internet protocols, they can be unusable with an incorrect system date.
- If the system auto-synchs to a time server, it can change its date back without warning.
I've seen all these things happen when the system date is changed to an incorrect value for testing purposes. It's much safer and cleaner to use other methods to check that the application behaves correctly with date/time related functions.