Session 15

Towards Graphical Applications in Java


810:062
Computer Science II
Object-Oriented Programming


On Homework 5

Several questions came up yesterday:

Any other questions?


Growing a Simple Graphical Program

Let's grow our first graphical Java program a simple BallWorld. And let's walk the walk, starting small and taking small steps:

Your reading assignment is to study the several versions of this growing program, including the last version: a BallWorldFrame that has a Ball, which is a Disc that moves itself.

Ideas to consider;

How do we test one of these graphical objects?


Testing Behaviors that Have Side Effects

How do we test one of these objects? Actually, this question came up in the context of Homework 5, too:

I think I've successfully made a "cannot be tested" class... Everything in this class has to do with getting input from the user and accessing that input. I can't think of any single way to write a test for this, unless I set the tests up to test a specific value and enter that exact value as input.

I know you love tests, but how can you test random input?

You don't have "random" input. You have arbitrary input. (... great session on randomness at my conference last week ...) So did our bowling game. Notice that we were able to test that class quite thoroughly, considering all of the interesting cases we could think of: open frames, spares, and strikes; in early frames and in the 10th.

We can do the same thing in Nim. For example, we might ask the user to pick up some stones. The user may enter a legal number of stones, or not. What shoule we test? The boundary cases of 0 and 3 are interesting. "Ordinary" legal value. Illegal values in both directions. These tests are really for the methods that receive and use the user's inputs.

Separate

the methods that read from the user

from

the methods that use the information.

This will make your code testable. Test the methods that use the information. If a method does nothing but use a Java snippet that we know reads a String from System.in, then we can trust BufferedReader.readLine() to do its job.

This approach makes your program better, too. If we ever want to change how the program interacts with the user, we will be able to replace only the methods that do interaction. The code that uses the information will stay the same! And if those methods are in different objects, then our program allows us to substitute new interaction objects without changing the "guts" of the Nim game!

Testing graphical applications is a bit tougher. How do we know that the program painted the ball at the right location in the window? Idea: Use a Graphics object that can tell us what we need to know...


Wrap Up


Eugene Wallingford ..... wallingf@cs.uni.edu ..... March 1, 2005