SAT: Socket Acceptance Test

Rick Mugridge, October 2002

Sat is a framework for testing socket-based servers. It uses Fit as its means of getting test input from an html file (such as this one), and for providing feedback on the tests.

Sat uses a SatFixture table to process tests (this class in turn extends ActionRowFixture, which provides a general approach to running commands on each row in turn).

The rows of the table are as follows:

• The first row specifies the fixture to use, satFit.SatFixture.
• The second row starts the server - it defines the class of the server that is to be created. This class implements sat.Server, so that sat can determine what port number to use.
• Subsequent rows are one of the following commands:
  • send with the messages to be sent in each cell corresponding to a client
  • rx with the messages that are expected to be received in each cell corresponding to a client
  • close closes the connection with the specified clients (those with a non-blank in their cell). This client column can't be used again.
  • sendRefused same as send, except that the connection is expected to be refused.
  • rxDiffers same as rx, except that the received message is expected to differ
  • rxTimesOut same as rx, except that the receive is expected to fail due to a timeout on the socket readLine().
  • rxRefused same as rx, except that the connection is expected to be refused.
  • timeOut specifies the timeout value in milliseconds, an int, on a readLine() from each client's socket. By default, 500.
  • postSendDelay specifies a sleep, in milliseconds, that occurs after each send, to help ensure that the server processes  messages in the desired order.  By default, 0.
  • delay Sleep for the specified number of milliseconds
  • comment Arbitrary text, which is ignored. Could be used to specify the state of the server of clients at any point in the interaction.
  • traceOn turns on the display of the messages being sent and received
  • traceOff turns off the display of the messages being sent and received
• The final row checks that the server has shut down correctly.

See TestSATXml.html for details of a fixture for handling XML messages.

Single Client Tests

Test Valid Response

ServerHelloHi expects to receive "<Hello/>" and if it does, it replies with "<Hi/>".

Test Wrong message sent first

If ServerHelloHi doesn't receive "<Hello/>" it replies with a message specifying what it expected:

Here we can check that we don't expect to receive "<Hi/>":

Test Extra Read

Extra Client

The mock server used here will only accept a connection with a single client. 

This tests that send and rx are refused with the second client.

Two Client Tests

Test Valid Response

Test wrong receipt on Second Client

Test Extra rx on Second Client

Test Close on Second Client

Timeouts and Post-Send Delays

I'm slack here, as I haven't bothered to automatically test that the delays occur as required.  An exercise for the reader.

Tracing

Test tracing

I'm slack here, as I haven't bothered to automatically test that the tracing output appears.  An exercise for the reader.

Summary