I recently had an inteview and inteviewer asked me this. Suppose We have a program that depends on system Clock. How will you test this program or write test cases.
I answered following
He then asked me how will you test the production Issue?
Can someone put some highlights on this question?
Thanks.Rick
This is one of those questions that's really just trying to see if you understand the issues involved. There's no "one right answer". From the question, it's not even clear what it is you're supposed to be testing. If the program relies on the system clock to be correct, then it should fail if the system clock is incorrect. If the program relies on the system clock being monotonic, it should fail if the system clock jumps backwards.
Basically, you need to test two categories of things. In the cases where the program is supposed to work, does it? (For example, if it's supposed to tolerate backwards clock jumps without fail, what happens if there's a backwards clock jump?) And in the cases where the program is supposed to fail, does it fail the way it's supposed to? (If it's supposed to refuse to authenticate if the clock is too far off, does it in fact do so?)
One issue is how you give it incorrect clock information. One way is the way you suggested -- add a call to intercept the program's "get the current time" function and give it different time. The downside of this approach is that the program might, somewhere deep in its code, get the time some other way that you failed to hook.
But the real problem with this approach is that it will likely cause the system to see inconsistent times. For example, say the program creates a file and then later calls stat to get the file's last modified time, which it compares to the, hooked, system time. The program will get the wrong age for the file unless you hook and offset all calls that return times.
The other way is to actually set the system clock incorrectly in the test harness.
Not sure what you mean by "Production issue", but I would create a stub of the Clock API. During the tests, I would specify that the system use this fake Clock API that I can control. During production, the system would simply default to the "normal" Clock API. You can specify which API to use by using a techinique called Dependency Injection.
There are plenty of tools that can assist developers in writing unit tests that require fake objects like mocks and stubs.
I have had to implement real C++ code that has used the system-clock to implement time-outs and had to be tested. I essentially did as you said. I had a Clock abstract base-class, and had the critical code use an instance of that type instead of using the real clock directly. My until tests used a mock TestClock derived class, for which I could manipulate the time arbitrarily. This allowed me to get good test coverage of the component that used the clock.
The real code used a PosixClock derived class, which delegated to the system clock. So how did I test that? All I needed to do was to demonstrate that the PosixClock indeed used the system clock. A unit test that read the PosixClock, slept for a short while until the clock evidently moved forward was enough. I additionally had a few integration test-cases demonstrating that the time-out functionality worked.
Together these three kinds of test-cases (clock-using component unit tests, PosixClock unit tests and integratino tests) demonstrated to my satisfactino that the code was correct.
