Creating an Application Test-Interface Class

Although creating a separate version of XTrackTest for WebART could work, we'd have to recompile the tests each time we wanted to switch between direct calls and WebART, and we'd end up with duplication (more than one assertFalse, for instance). To avoid these problems, we'll create a new application test-interface class to hold just the methods (login, createUserId, and so on) that are going to be different between the two interfaces.

We'll call this class XTrackTestInterface. It looks like Listing 23.1.

Listing 23.1 XTrackTestInterface.java

 public class XTrackTestInterface {    public boolean login( String id,String psw) {         return false;    }    public boolean createUserId( String id, String psw,                                 String email) {         return false;    }    public boolean deleteUserId( String id) {         return false;    } } 

You can think of this as a kind of null-test interface to the system. The methods don't do anything; they just unconditionally return false. Note that this class has no extends clause. It isn't based on any other thing, like the other classes we've used so far. Instead, it's going to provide the base for the two interfaces we need: the direct-call interface, which we already have working, and the WebART interface, which we're going to create.