5.2 Naming Conventions for Integration Tests

Each Integration Testing file will be called ITCLASSNAME.py, where CLASSNAME is the name of the class the test is designed for. For example, the integration test file for Mean.py will be named ITMean.py.

Each individual Integration Test will be named after the function that it tests. The format of this name will be the function name, followed by the word Test, followed by the number of the test. For example, integration tests for the getName function should be called getNameTest1, getNameTest2, and so on.

5.2.1 Breakdown of SAM

Firstly, the breakdown of SAM is based around the MVC architecture, as explained in section 1.2. Typically in MVC, the Controller class interacts with the user and controls the entire system, the Model module processes data and the View module displays data to the user. However, seeing as SAM must perform large amounts of analysis, it has been chosen to split up the usual Model module into two: one (also called Model) handles the loading and reading in of data, and the other (Analysis) handles the processing (analysis) of data. Also, the View module has been renamed to Output. This modified version of MVC corresponds to using SAM for doing an analysis. Also, there is an extra module not usually part of MVC - the Logger, which is responsible for creating network log files (that will be used by SAM for analysis). This extra module corresponds to a separate function SAM may perform. This breakdown can be seen in Figure 1.

Figure 1: Shows the modified MVC architecture used for SAM, including the decomposition of the model module into Model and Analysis modules.

5.2.2 Thread Based Integration

In the SRS and DDD, detailed use cases were developed to give examples of SAM's behavior. These use cases are invaluable, since they show the effects of one particular user event or input to SAM, which corresponds to independent ways SAM may be used - ie, one particular thread of execution. Clearly, it can be seen from the breakdown of SAM that SAM may be used for two independent functions - Logging and Performing Analysis. These two functions correspond to different sets of use cases in the SRS and SADD (as shown below), and hence are the two threads of execution.

Thread 1: Performing Analysis: `Load File' then `Select information relevant to analysis' then `Perform analysis' then `Output result of analysis'
Thread 2: Logging: `Create Log' then `Select information relevant to logging' then `Do log' then`Log file created'

Thread Based Integration involves building then integrating all the classes involved in a particular thread, where each thread involves some input, some processing and some output. Here, this corresponds to the Controller and Logger modules for Thread 2, and the Controller, Model, Analysis and Output modules for Thread 1.

The advantages of Thread Based Integration are:

• Different threads of execution can be built and tested in parallel.
• It is useful for user interface and event driven systems like SAM.
• Once a thread has been successfully built and tested, it can be shown to the Client.
• Important classes can be integrated early to allow maximum testing.
• The structure of the system can be assessed early.

5.2.3 Bottom Up Integration

However, to simply choose Thread Based Integration is not enough, since it does not define the order in which each thread (and hence each class of each module) will be coded and tested, only the overall order. Therefore, another strategy needs to be chosen for coding and testing the modules (Controller, Logger, Model, Analysis and Output).

For all the modules (except Controller - see next section), the chosen strategy is Bottom Up. Within each module, the lower classes perform the main computations and calculations, therefore it is important that they get adequately tested. This also reduces the need to write stubs, since the lowest level classes (ones that do not call other classes) are coded and tested first.

5.2.4 Top Down Integration

The one exception to the Bottom Up strategy chosen is the Controller module. This module controls the entire system and directs each other module as to what to do. Clearly, it would be unacceptable to code this module last (as would be done in Bottom Up). The topmost class of the Controller module (called MainWindow) must be in fact the first class coded, since the architecture of the system depends on this, and hence architecture flaws can be detected early. This corresponds to a Top Down strategy for the Controller module - coding the topmost class first (and writing stubs), then filling in the stubs with the lower classes.