Easy clock simulation for testing a project

Consider testing the project you've just implemented. If it's using the system's clock in anyway, testing it would be an issue. The first solution that comes to mind is simulation; manually manipulate system's clock to fool all the components of your software to believe the time is ticking the way you want it to. How do you implement such a solution?

My solution is: Using a virtual environment (e.g. VMWare Player) and installing a Linux (I leave the distribution to you) and manipulating virtual system's clock to create the illusion of time passing. The only problem is, clock is ticking as your code is running. Me, myself, am looking for a solution that time will actually stop and it won't change unless I tell it to.

Constraints: You can't confine the list of components used in project, as they might be anything. For instance I used MySQL date/time functions and I want to fool them without amending MySQL's code in anyway (it's too costy since you might end up compiling every single component of your project).

Write a small program that changes the system clock when you want it, and how much you want it. For example, each second, change the clock an extra 59 seconds.

The small program should

• Either keep track of what it did, so it can undo it
• Use the Network Time Protocol to get the clock back to its old value (reference before, remember difference, ask afterwards, apply difference).

From your additional explanation in the comments (maybe you cold add them to your question?), my thoughts are:

You may already have solved 1 & 2, but they relate to the problem, if not the question.

1) This is a web application, so you only need to concern yourself with your server's clock. Don't trust any clock that is controlled by the client.

2) You only seem to need elapsed time as opposed to absolute time. Therefore why not keep track of the time at which the server request starts and ends, then add the elapsed server time back on to the remaining 'time-bank' (or whatever the constraint is)?

3) As far as testing goes, you don't need to concern yourself with any actual 'clock' at all. As Gilbert Le Blanc suggests, write a wrapper around your system calls that you can then use to return dummy test data. So if you had a method getTime() which returned the current system time, you could wrap it in another method or overload it with a parameter that returns an arbitrary offset.

Encapsulate your system calls in their own methods, and you can replace the system calls with simulation calls for testing.

Edited to show an example.

I write Java games. Here's a simple Java Font class that puts the font for the game in one place, in case I decide to change the font later.

package xxx.xxx.minesweeper.view;

import java.awt.Font;

public class MinesweeperFont {

    protected static final String FONT_NAME = "Comic Sans MS";

    public static Font getBoldFont(int pointSize) {
        return new Font(FONT_NAME, Font.BOLD, pointSize);
    }

}

Again, using Java, here's a simple method of encapsulating a System call.

public static void printConsole(String text) {
    System.out.println(text);
}

Replace every instance of System.out.println in your code with printConsole, and your system call exists in only one place.

By overriding or modifying the encapsulated methods, you can test them.

Another solution would be to debug and manipulate values returned by time functions to set them to anything you want