 | 1.6 Extra meanings for ∈, ∉, and hd |
| 
| 1 Changes to RSL |
| 
| 1.8 Features of RSL not supported |
|
| 1.7 Test cases |
1.7 Test cases
There is also a new extension to RSL to support interpretation and
translation. In addition to type, value, variable, etc. declarations
you can now have a test case declaration. The keyword test_case is
followed by one or more test case definitions. Each test case
definition is an optional identifier in square brackets (just like an
axiom name) followed by an RSL expression. The expression can be of
any type, and it can be imperative.
Test cases are not an official part of RSL. You can think of them as
no more than comments (although the type checker will report errors in
them). But to an interpreter they mean expressions that are to be
evaluated. So if you wrote
you would expect to see the interpreter output
Test cases are interpreted in order, and the result of one can affect
the results of others if they are imperative. Suppose, for example,
we have have an imperative (integer) stack with the usual functions.
Then, if the stack variable is initialised to empty, the following
test cases
|
| | | | | | | | | | | | |
| test_case |
| [t1] push(1) ; push(3) ; push(4) ; top(), |
| [t2] pop() ; pop() ; top(), |
| [t3] pop() ; is_empty()
|
should produce the following interpreter output
Test case declarations are only interpreted or translated
if they occur at the top level. This means that you can conveniently
test modules "bottom-up", since test cases in lower level modules
will be ignored when higher ones are tested later.
We need to be precise about what we mean here by the "top level".
Suppose we define a scheme X. We might add some test cases
to it, or we might define a separate scheme to test X, defined by
|
| | | | | | | | | | | | |
| scheme TEST_X = extend X with class test_case ... end
|
But it might be the case that both X and TEST_X
contain test cases. It is
then assumed that the intention is to translate and execute X and
TEST_X separately, so that in TEST_X the test
cases should not include those from X. To be more
precise, for the purpose of deciding what test cases are included, the
"top level" means the class of the module given as input to the
translator or interpreter, and:
- test cases from global objects (apart from the top level module,
which may be an object) are not included
- test cases from embedded objects (objects defined within
classes) are not included
- in "extend class1 with class2", the test cases from
class1 are not included if class1 is a scheme instantiation
- otherwise all test cases are included
Chris George, April 17, 2008
| 1.7 Test cases |
| 1.6 Extra meanings for ∈, ∉, and hd |
| |
| 1 Changes to RSL |
| |
| 1.8 Features of RSL not supported |
|