Test-Interaction as an Interface / Service Definition

The introduction to test-interactions and other sections covering the use of test-interactions have not addressed the topic of different implementations of the same test-interaction. As will be seen testware can benefit from providing a number of implementations of a test-interaction. Different tests will use different implementations for different purposes.

With this approach the definition of the test-interaction actually defines the common aspects of a set of interaction implementations. For example the behaviours that can be reported. The test-interaction defines the interface that all implementations support.

Support For Different Client Testware Control Requirements

Variations in the way different implementations of a test-interaction can be controlled come at two levels:

• Variation of which aspects of the interaction can be controlled.
• The way that variable values are passed to the implementation.

Implementations With Different Degrees Of Control

An example of a test-interaction where different implementations permit different degrees of control by client testware is an interaction to log onto the system called, surprisingly, Logon. There is a regularly used and fixed user name called 'sa'.  In this case it makes sense to provide:

• A Logon test-interaction where the user name and password are variable and controlled by the Test-Interaction Operation Specification.
• A Login test-interaction that always uses 'sa' and the associated password value.

The first can be used in cases where the user is not 'sa' but when user 'sa' is required the fixed interaction is used. The fixed interaction requires less configuration prior to use and avoids duplication in client testware. A similar situation can be envisaged with a place order interaction. There could be one version that always orders a single item on normal delivery and one where all order characteristics can be varied.

This is illustrated below

Obviously the implementations of the more specialised interactions Logon_Sa and CreatOrder_Simple can build on the testware used to implement the more generic ones. This could be done either by the specialised interactions operating as formal clients of the generic implementations or by sharing common implementation code. This is shown below:

Alternative Ways of Communicating Interaction Parameters

Another way in which implementations vary is the way they expect to be provided with the values of the parameters that control the interaction. Different tests may warrant providing data in different ways. Taking the CreateOrder_Gen test interaction two ways of using this would be either to define the StockCode, Quantity, Delivery and Promotion code in the operation specification or to identify a file from which the next set of values should be read. This is shown in the diagram below:

Summary

As can be seen from the diagram in the preceding section multiple concrete implementations can exist to support the different control requirements of client testware. Control requirements vary in terms of what can be controlled and how control information is communicated. What can be controlled determines the conceptual parameters of the implementation. How control information is communicated determines the control parameters of the implementation.

Different Sequences Delivering Equivalent Effects

When a test-interaction operates a sequence of exchanges occurs between the testware and the system. These exchanges may be a mix of ones performed directly from this test-interaction and ones that occur when other test-interactions are used as workers.

Now though previous discussions have identified test-interactions in terms of what they do - Logon, EnterOrderDetails, CreateOrder - the testware needs to recognise that there may be different ways to do a task, particularly where they can be done through different interfaces. For example it could be that an order can be created via a dedicated client, via a web client or via a web service. On the dedicated client there may be a number of mechanisms supporting the search for and selection of the stock code.

Strategies for dealing with this in the testware range from:

• Embody one standard way for each interface in a test-interaction and address all others as individual tests working on lower level test-interactions.
• Use test-interactions to implement all probable sequences of operation on each interface and cover improbable and erroneous use in individual tests.

 As a minimum test-interaction is provided for each interface to support efficient data driven testing to check the implementation of data validation.

So it can be seen that there can be a number of bits within the software that, when the system is operating correctly, do the same thing but exercise different bits of the system.  These could be totally independent test-interactions but that is not the best model to adopt. The testware is more structured and understandable if variations in the way a task is done are treated as different implementations of an interaction. This approach also enables test based plug and test reuse of test-interactions. The relationship of different implementations to the parent test-interaction is shown below:

Adopting this systematic approach to organising similar interactions into a group of implementations of a single test-interaction has major benefits. In particular it provides a regular structure and lends itself towards even more reuse through the use of plug and test selection of interaction implementations.