Using remoteWebDriver, can I change the time on the executing system? [duplicate]

Question

I'm trying to functional test some code that is dependent on reading the client date, and I want to validate that it does so correctly. Locally, I can change my system date using Java and run the test using Selenium, but I want to run my tests with RemoteWebDriver. Is there some way I can change the date on the client system? If not, can I spoof the date somehow?

Answer 1

In short the answer is no, because the webDriver is exactly that. It drives a browser. It does not know how to communicate with the system level APIs.

Before I go into something that could help you, I'd like to point out that if your Selenium test is so specific that it requires the system date to change then that is a major 'test smell' to me. If it is possible then I would consider automating that with a 'unit' or 'integration' test.

If you don't have access to the source code and you absolutely must automate this test with Selenium then you can look into a Java library that allows you to run a shell command. I don't know what operating system you're running otherwise I'd point you to something specific, but I'd recommend googling "How to change date on remote machine with Java"

Answer 2

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.