Purpose of this assignment:

• To encourage you to use JUnit and do unit testing
• To get some programs that I can use (and give out to future classes) to help them with JUnit testing

Idea of the assignment:

The whole point of JUnit is to make testing easy--one click and you test everything. (Of course, you still have to create the tests beforehand.) JUnit calls your methods and tests whether they return the correct results. But JUnit does not give you much help in automating GUI testing or in testing output for validity.

Your assignment is very open-ended. Figure out how to make JUnit better able to cope with GUIs or with methods that perform output. You don't have to do both.

Details:

GUIs:

I think the best way to aid in GUI testing is to write a package containing methods to emulate the various actions the user could take. For example, you could have methods such as clickButton and adjustScrollbar. The AWT already has methods for retrieving information from Components (e.g. getValue() for Scrollbars), so you probably don't need to define these methods.

Here's a simple method for creating events that could be specialized into more useful methods:

public void fakeAction(Component c) {
    getToolkit().getSystemEventQueue().postEvent(
         new ActionEvent(c, ActionEvent.ACTION_PERFORMED, ""));
}

Other approaches are possible. For example, Component has a getListeners(listenerType) method; if you know the listeners, maybe you could access them directly. My first impression is that posting events is probably easier, but I haven't explored the matter.

If your package is to do the right thing in all cases, some care is required. For example, even something as simple as a button click can create Events containing differing information--see the setActionCommand method in Button for details. In general, if you create an Event containing the correct information, I think everything should be OK.

Finally, I've been assuming the AWT, which has a small number of controls to consider. I'd be at least as happy with a package for Swing. There are far too many Swing components to do a good job in less than a semester, so if you would like to take this route, just consider the Swing components that have AWT equivalents (JButton, JScrollbar, etc.).

Output:

The problem here is to capture the output and compare it to some known, correct output. If it's a lot of output, probably you want to put the correct output in a file and read in the file to compare it to what the method produces. If it's only a line of output, you probably want to put it directly into the test method as a String.

I can think of various ways to capture the output. If the output is to a file, the file can simply be read in again. If it's to System.out, you can use System.setOut(printStream) to direct it elsewhere. A Java PipedOutputStream can be connected directly to a PipedInputStream; this might be helpful. Since Java I/O is so flexible, I certainly don't expect you to do everything;

Since this option is less clearly defined, but I really hope someone will tackle it, I'll give more credit for a good job on this part.

Due date:

Monday, December 8, before midnight.