Transformation of Applicative Specifications into Imperative ...

11.2. CHOICE OF TESTS
This means that a black box test should be performed to test the functionality,
both for correct and incorrect input. A white box test could be
performed in order to test the program structure but as the logic of the
program is very straight forward and because many of the branches in the
program structure can only be reached through system errors a black box
test of the control module is to prefer.
11.2 Choice of Tests
The considerations discussed above leads to the following tests of the transformer:
1. A grey box test of the program as a whole. In this way all parts of the
program will be tested.
2. A black box test of the control module.
The decision that the system should be tested as a whole is made for
several reasons. Parts of the lexer, parser, RSL AST and the visitors are
already tested in the RSL2Java tool project. By making a thorough test of
the whole system, all parts of these components will be used. Furthermore,
the possibility that e.g. an error in the parser would be balanced out later
in the process of the transformer is negligible.
11.2.1 Grey Box Test of the Program
The grey box test of the program was performed by transforming different
applicative RSL specifications, both transformable and not transformable
specifications, and by introducing one or more types of interest. The results
of the transformation were then compared with the transformation rules of
Chapter 6 if transformable, and with the conditions for transformability if
not transformable. If transformable, the result of the transformation was
also type checked using the RSL type checker.
The test specifications are chosen such that all corners of RSLA are
reached. That way all parts of the lexer and parser, the visitor modules,
the RSL AST code and the transformer module itself are tested.
Furthermore, specifications that could lead to problems are tested. These
are chosen based on knowledge of the inner working of the program. An
example is that the expected type of a value expression has to be carried on
the right way through the transformation. For example, when transforming
the product expression (x, (y, z)) of expected type Int × ( Bool × Text),
then x should have the expected type Int and (y, z) should have the expected
type Bool × Text. But then again it is not necessary to test whether y has
expected type Bool and z has expected type Text during the transformation
due to the recursive structure of the transformer module.
121