What Were Testing Testing the Bank Application

book about how to build distributed applications, and discussing testing in general is simply outside the scope of this book. In general, as soon as the framework is in place, and th e application can be run as a distributed application, testing should commence. Writing the test code as soon as is feasible, and running the tests as often as is reasonable, helps guarantee that mistakes will be spotted quickly. This, in turn, helps make them easier to repair.

13.1 Testing the Bank Application

After all of the alterations in Chapt er 11 and Chapt er 12 , we now have a version of the bank example that we think is threadsafe and scalable. [ 2] If you can make a claim, you should be able to provide evidence that the claim is correct. So we will now proceed to test the code weve put in place. [ 2] Contained in the package com.ora.rmibook.chapter12.bank.scale and its subpackages.

13.1.1 What Were Testing

Any reasonable set of tests checks two different things: correctness and scalability. Correctness is a simple property; were testing whether, for an isolated client, the application actually works. The questions we have to ask ourselves are: • Can the client connect to the server? • Can the client perform remote method calls? • Does the server do the right thing when the client makes a method call? Scalability, on the other hand, is a more subtle property. Basically, were concerned about the behavior of the application as the load increases. This encompasses five basic questions. In order of descending importance they are: Is the application still correct from the point of view of a single client? If the application no longer functions correctly when there are multiple clients, then weve got a serious problem. Its probably thread related; we probably have two client requests that interfere with each other. Is the applications performance under typical client loads acceptable? This is the single most important performance test. If the user cant use the application because its too slow, then the application is useless. Can the application handle peak loads? The application is allowed to get slower when usage unexpectedly spikes. But it shouldnt crash, or consume disproportionate amounts of server resources. How does the applications response time degrade as the number of clients increases? The applications performance will degrade as we add clients. The goal is to have the performance degrade gracefully. Typically, the way you measure this is in terms of average response time versus the number of users e.g., When there are 30 users, the average response time is 134 milliseconds for a withdrawal. What wed love is a flat relationship: constant response time as the number of users increase. But since each additional user will consume extra resources and computing time, thats impossible once a server starts to get busy. The best we can hope for is a linear relationship between the number of users and the the response time. This is hard to achieve. How does the application behave over long-term usage? The issues here revolve around the performance of the server when you leave it running for an extended period of time. Does it leak memory? Does it gradually lose the ability to respond? The memory and resource footprint of the server when it has no clients should be the same, no matter how long the servers been running. And the server should have the same performance characteristics after five weeks in operation as when it was first started. If this isnt the case, and there is no explanation for why the servers profile has changed, then the server is not ready to be deployed.

13.1.2 How to Test a Server