Testing Multiple Representations


Few systems these days are written in a single, compiled language with a single data representation. More likely, they are a composite of compiled servers, perhaps written in C++, and interpreted clients, perhaps written in Java, whose screen presentation is dynamically computed as the representation is pulled from a database. The customer data is structured in a relational architecture and must be repackaged to reflect the object-oriented architecture of the computational logic.

Several features of these systems are important from a testing perspective:

  1. interactions between two data models

  2. interactions between pieces written in different languages

  3. interactions between static and dynamic portions of the program

The first step in addressing these features is a thorough unit test process. Each piece of the system, especially the dynamic pieces, should be exercised in its native language. The second step is to test the interactions across language and representation boundaries. The focus of these tests should be boundaries on the data types for parameters that are passed between code written in different languages.[2] We implemented the tic-tac-toe game in Java using a variation of our game framework. It included a strategy component that determined the next move a computer player would make. We implemented the strategy piece in C++ and used an interface between Java and C++ to return the results to the main Java program. Our initial testing found defects such as data-word alignment issues that resulted from misunderstanding the type mapping between languages.

[2] This same situation will arise when one data type is converted to another. This type of testing should be conducted to ensure that conversions are working correctly.

Tip

Test the interfaces between two languages to determine that a complete object is transferred. First, be certain that each connection in either direction is exercised. Second, validate the test results by examining the transformed objects in detail to ensure that nothing is missing or misrepresented. Measure coverage by covering all of the primitive types of each language.Testing here is primarily implementation-based.


One example of testing the dynamic aspects of a system involves the mapping from one type of representation to another. For an XML-based system, the first step is to use a validating parser to determine that the XML itself is of the correct form. The portion of the program logic that manipulates the XML description is then tested under the assumption that the description is correct. This validation of input data by a validating XML parser is conceptually the same as the use of a direct SQL query facility to validate the results of tests in a system based on a relational database or the object viewer for an object-oriented database. That is, first determine that the inputs are correct and then address the correctness of the outputs.

Another example of mixing system types is the fairly common approach of using a relational database as the back end to a system that has an object-oriented front end. The interface between the two models provides an opportunity for incorrect mapping as data coming from the relational side is grouped into objects. The test suite should include validation of the newly created objects.

Tip

Exercise all of the interfaces between two data representations by identifying existing test cases that together map a representative of each equivalence class. Verify (1) that the mapping from one representation to another happens correctly, (2) that everything is mapped in each direction (completeness), and (3) that each element is mapped the same all the time (consistency).




A Practical Guide to Testing Object-Oriented Software
A Practical Guide to Testing Object-Oriented Software
ISBN: 0201325640
EAN: 2147483647
Year: 2005
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net