Maintenance Document

Before any coding began we decided on a design and testing structure for our project. Each main module in the project would have an author and perhaps an assistant. They could perform personal testing but each module should be given to another person to test before being accepted. Any modifications to the module would require a further test by the same person. In reality we found that there was insufficient time to do this and so an alternative strategy was adopted. Modules were built by an individual and tested by the same person. During integration testing errors were found and corrected by all those involved.

Most of the objects on the object diagram were tested using the same technique. Initial drivers were made to test a single object but as tested objects became available these were used in later drivers. The driver would provide a menu with all the public methods of the object. The tester would select a method, enter any parameters required, and the object would be called. Stubs would be provided for the test object to interact with. These would display messages when they had been called and if necessary read in return values from the tester. Time constraints meant that a coverage testing strategy was not implemented. Instead interesting and important values were used as examples. Although this speed up the testing of some objects it did miss other faults which were only found later during testing of larger sections of the spreadsheet.

The formula line object has a simple construction and so could be tested with only a few test cases for getting and putting formula. The results could be seen directly from the calls made to stubs for the grid and compiler object.

The notifier was only dependent on the cell object and so its driver only had to provide stubs for this. It held and array of cells could be signalled to the notifier. Testing consisted of adding cells and then starting a notification cycle. The driver proved to be awkward to use because each cells dependencies had to be entered three times.

The grid object was also only dependent on the cell object but required a more complex harness to cope with the larger number of methods. In addition to looking up legal and illegal cell names and cells, testing was done on the space saving system which allows cells that were no longer in use to be removed.

The cell object acts as a communication hub for the spreadsheet and the driver required a large number of stubs. Each test required large amounts of typing and produced substantial results. Also at the time of testing the request object had not been coded, stubs for it would have been difficult, and so testing did not include receiving and sending of data requests.

The cache object was tested by storing images for a number of cells of various sizes. The cache object does not implement the removal of images under memory shortage and so testing was not extensive.

The compiler object is loosely coupled to the rest of the internal model. The driver collected formulae to be parsed by the compiler and provided a stub in place of the grid. The AST had to be enhanced so that a flattened, human readable, version could be displayed. Tests included a variety of standard formulae.

A large scale test for the formula line, notifier, compiler, grid and half of the cell could then be performed using a simple test driver. Formulae were added and extracted and the update messages returned by the cells showed the function of the system. Again a variety of standard formulae were entered, this time into several cells, cycles were set up and then removed.

The interpreter object required a cell stub during testing, the compiler used to produce the ASTs for the test. A number of numeric and textual formula were used in the compiler for a number of cells. Images could be loaded from disk but not displayed within the driver. It was found that the interpreter could not handle cell referencing, although attempts were made to repair this it was impossible within the remaining time.

The final test driver was for the spreadsheet object which contains the entire Internal Model. It also tested several other components including the display object and parts of the cell object which had not been tested before. Formulae could be added to cells and data values retrieved. A selection of formula showed up several errors in already tested objects because of the large amount of test data which they were exposed to within a working spreadsheet.

In connecting to the Internal Model to the External Model it proved useful to construct another interface to convert between C++ and C. Test values where formula which were entered into the spreadsheet. The External Model was then extended to make heavier use of the Internal Model which showed up several more errors which had not been caught in the earlier non-coverage testing.

During the various stages of testing and in object construction and integration there were several occasions when incomplete testing was done. If more time had been available it would have been possible to have used additional drivers to test some of the smaller objects, to have used additional stubs to do more complete testing of larger objects, and to plan coverage testing for all objects.