Test frame updating in CPM testing of Prolog programs

Abstract

Category Partition Method (CPM) is a general approach to specification-based program testing, where test frame reduction and refinement are two important issues. Test frame reduction is necessary since too many test frames may be produced, and test frame refinement is important since during CPM testing new information about test frame generation may be achieved and considered incrementally. Besides the information provided by testers or users, implementation related knowledge offers alternative information for reducing and refining CPM test frames. This paper explores the idea by proposing a call patterns semantics based test frame updating method for Prolog programs, in which a call patterns analysis is used to collect information about the way in which procedures are used in a program. The updated test frames will be represented as constraints. The effect of our test frame updating is two-fold. On one hand, it removes ''uncared'' data from the original set of test frames; on the other hand, it refines the test frames to which we should pay more attention. The first effect makes the input domain on which a procedure must be tested a subset of the procedure's input domain, and the latter makes testers stand more chance to find out the faults that are more likely to show their presence in the use of the program under consideration. Our test frame updating method preserves the effectiveness of CPM testing with respect to the detection of faults we care. The test case generation from the updated set of test frames is also discussed. In order to show the applicability of our method an approximation call patterns semantics is proposed, and the test frame updating on the semantics is illustrated by an example.

Integrating Software Testing and Run-Time Checking in an Assertion Verification Framework

“…The resulting language can express for example the input data for performing such unit tests, the expected output, the number of times that the unit tests should be repeated, etc. In contrast to previous work in this area (e.g., [1], [17], or the unit test framework recently included in SWI-Prolog [16]), a key contribution of our approach is that these unit tests blend in with the assertion language and reuse the overall framework. In particular, only test drivers need to be added because the assertions and their run-time tests act as the checkers for the cases defined by the unit tests.…”

Un marco unificado para análisis de recursos y tiempo de ejecución, validación dinámica y pruebas unitarias = a Unified Framework for Resource and Execution Time Analysis, Run-Time Checking and Unit-Testing

“…Regarding unit-testing, there are previous works in this area, e.g., [8], [69], or the framework included in SWI-Prolog [67], called plunit, which also runs on SICStus Prolog and provides a portable testing framework. In the SWI-Prolog unit-testing framework, unit-test specifications are written in the same source code module or in a different file with the same name as the module being tested, but the framework does not allow to write unit-test specifications in the same module that contains the predicates being tested.…”

“…The resulting language can express for example the input data for performing such unit tests, the expected output, the number of times that the unit tests should be repeated, etc. In contrast to previous work in this area (e.g., [8], [69], or the unit test framework recently included in SWI-Prolog [67]), a key contribution of our approach is that these unit tests blend in with the assertion language and reuse the overall framework. In particular, as mentioned before, only test drivers need to be added because the existing run-time assertion checking machinery is used as a checker for the cases defined by the unit tests.…”