Build simple test objects

3. Repeats After all the threads are done, a GUI displays the results, as shown in Figur e 13- 1 . Figure 13-1. GUI testing framework for our distributed application Note that this isnt particularly detailed information. We find out whether the servers worked correctly under testing and some preliminary information about the behavior under loads. More accurately, we find out the average response time, the longest response time, and how many requests ran into locks on an account. Ideally, wed like to analyze the data further. For example, wed like to know more about the distribution of response times. If 10 percent of the responses were very slow, and 90 percent were very fast, then we probably ought to investigate further. Similarly, we should run the tests with varying numbers of clients to see how the performance changes as we change the load. However, even without that, running this test every night and seeing that the code performs similarly no failures, small average response time is a good and useful thing to do. Certainly, if I were project lead, and I knew that new tests were added every time remote functionality was added, Id be thrilled to get this sort of information every morning. We will now walk through the design and implementation of our testing application in more detail, following the first five steps outlined earlier.

13.1.3.1 Build simple test objects

There are three methods we can call, each of which needs to be tested. In addition, we need to test the ability of clients to find and connect with servers. We do this by building four classes: an abstract class named Test and three concrete subclasses corresponding to the three methods we can invoke remotely. Test is responsible for three things: it connects to an individual account server, it defines a set of possible outcomes things such as, The account was locked, and it keeps track of how long a remote invocation takes. In addition, Test implements the Comparable interface so that instances of Test can be sorted. The concrete subclasses handle the details of invoking a particular method. The time information that Test keeps track of isnt particularly accurate. Test uses System.currentTimeMillis , which is accurate only to 50 milliseconds. Nonetheless, the rough order of magnitude calculations are quite nice. Here is the source code for Test : public abstract class Test implements Comparable { public static final String UNABLE_TO_CONNECT = Unable to connect; public static final String ACCOUNT_WAS_LOCKED = Account was locked; public static final String REMOTE_EXCEPTION_THROWN = A remote exception was thrown; public static final String FAILURE = Operation completed with incorrect result; public static final String SUCCESS = Everything was cool; public String status; public long duration; public long startTime; public String accountName; private NameRepository _nameRepository; private String _className; protected abstract String performActualTestString idNumber, Account3 account; protected abstract String describeOperation ; public TestNameRepository nameRepository { _nameRepository = nameRepository; _className = getClass.getName ; } public void performTestString idNumber { accountName = _nameRepository.getAName ; Account3 account = null; try { account = Account3Naming.lookupaccountName; } catch Exception e {} if null==account { status = UNABLE_TO_CONNECT; duration = 0; return; } startTime = System.currentTimeMillis ; status = performActualTestidNumber, account; abstract method implemented in subclasses duration = System.currentTimeMillis - startTime; return; } public String describeOutcome { return Attempted to + describeOperation + account + accountName + at + startTime +. \n\t The operation took + duration + milliseconds and the result was : + status + \n; } public int compareToObject object { first sort is alphabetical, on class name, second test is on account name third test is by startTime, fourth test uses objects hashcode .... } protected Money getRandomMoney { Sometimes the money will be negative. But, most of the time, well send in positive amounts. int cents = -2000 + int Math.random 100000; return new Moneycents; } } Given the implementation of Test , the actual test objects are as simple as they can be™they simply test a single method to see whether it functions correctly. Here, for example, is the source code for MakeWithdrawal : public class MakeWithdrawal extends Test { public MakeWithdrawalNameRepository nameRepository { supernameRepository; } protected String describeOperation { return make a widthdrawal from ; } protected String performActualTestString idNumber, Account3 account { Money balance = null; Money amountToWithdraw = getRandomMoney ; Money correctResult; Money actualResultingBalance; try { balance = account.getBalanceidNumber; correctResult = balance.subtractamountToWithdraw; account.makeWithdrawalidNumber, amountToWithdraw; actualResultingBalance = account.getBalanceidNumber; } catch RemoteException remoteException { return REMOTE_EXCEPTION_THROWN; } catch OverdraftException overdraftException { ifamountToWithdraw.greaterThanbalance { return SUCCESS; } else { return FAILURE; } } catch LockedAccountException lockedAccountException { return ACCOUNT_WAS_LOCKED; } catch NegativeAmountException negativeAmountException { if amountToWithdraw.isNegative { return SUCCESS; } else { return FAILURE; } } ifamountToWithdraw.greaterThanbalance { return FAILURE; } if amountToWithdraw.isNegative { return FAILURE; } if correctResult.equalsactualResultingBalance { return SUCCESS; } else { return FAILURE; } } } There are two things to note here. The first is that we really are using our distributed exceptions quite heavily. Its important to make sure that the server really does catch improper arguments e.g., an attempt to withdraw a negative amount, and that when the server does throw an exception, it is does so for the correct reasons. The second point to note is that its not entirely obvious what a failure means. Suppose performActualTest fails. This could be due to either of the following reasons: • The lock wasnt set, and another client thread managed to perform an operation. • The actual withdrawal code is flawed. The right way to distinguish between these is to write additional tests that check only the locking mechanism. If the locking mechanism works, then we know the withdrawal code must be flawed. In our case, its not such a big deal; our codebase is small enough to simply spot errors once we have a good hint. However, in larger applications, distinguishing between possible causes of error is incredibly useful. This is an important point. When youre building fine-grained tests, they rely, to a large extent, on the existence of many other fine-grained tests. Every test you add makes the others work better, and makes the testing suite more effective. The general rule of thumb: if you can talk about something and have a name for it e.g., the locking mechanism, you should be able to test it.

13.1.3.2 Build aggregate tests that test entire use cases