15.4. Testing

The entire testing procedure is beyond the scope of this book. Following is a short summary of how the tests proceed. The client and I developed our testing strategy as the design was being developed ("Plan for Testing"). Because we applied the guidelines of Extreme Separation, there are only a few methods to test in each class.

1. For each ParticularMessage :

   1. Ensure that convert_to_text( ) and convert_from_text( ) both work.

   2. Create a message with test values, call handle( ) , and check that the returned Message is of the correct type and has the appropriate values.

2. For each set of Message s involved in an operation method, such as do_particular_operation( ) :

   1. Call do_particular_operation( ) .

   2. Check the return values from do_particular_operation( ) to see if they match the testing oracle (the definitive source of what should be the results of a test).

3. For a sequence of operation methods:

   1. Call the set of methods.

   2. Check the values along the way to see if they match the testing oracle.

You can run the second and third tests in a variety of environments by varying the implementations of TextMessageDispatcher , ClientEnvironment , and ServerEnvironment .

The classes that implement interfaces allow for mixing and matching of implementations during testing ("Build Flexibility for Testing"). Both ClientMessageDispatcher and ServerMessageDispatcher implement the MessageReceiver . To test that the handle( ) method for each Message works correctly, do_particular_operation( ) can call the implementation provided by ServerMessageDispatcher directly. Testing can proceed without involving the network or decoding/encoding text.

Both ClientSocket and ServerMessageReceiver implement TexTReceiver . ClientMessageDispatcher can talk directly to the ServerMessageReceiver implementation. Now the flow can be tested with the addition of conversion to and from text.

Test versions of TextSender and MessageReceiver can be created that return failures to see if do_particular_operation( ) responds correctly.

Testing is about being able to alter one little thing and see the differences in the results. Regardless of how things are hooked up (in any one of three ways), the results should be the same, if there is no network failure.

With the flexibility in the design, you can test do_particular_operation ( ) multiple ways:

• It can be on the same machine as the server and connect via the localhost socket (127.0.0.1).

• The client do_particular_operation( ) method can run a different machine than the server.

• Multiple instances of the client do_particular_operation( ) method can run on the same or different machines by using different ClientEnvironment.ComputerInformation . This checks for how well the process of dealing with multiple simultaneous users works.

• Tests can be run with either a test or a production database.