Prolog Unit Tests
AllApplicationManualNameSummaryHelp

  • Documentation
    • Reference manual
    • Packages
      • Prolog Unit Tests
        • Introduction
        • A Unit Test box
        • Using separate test files
        • Running the test-suite
        • Tests and production systems
        • Controlling the test suite
        • Auto-generating tests
        • library(test_cover): Clause coverage analysis
        • Portability of the test-suite
          • PlUnit on SICStus
        • Motivation of choices

9 Portability of the test-suite

One of the reasons to have tests is to simplify migrating code between Prolog implementations. Unfortunately creating a portable test-suite implies a poor integration into the development environment. Luckily, the specification of the test-system proposed here can be ported quite easily to most Prolog systems sufficiently compatible to SWI-Prolog to consider porting your application. Most important is to have support for term_expansion/2.

In the current system, test units are compiled into sub-modules of the module in which they appear. Few Prolog systems allow for sub-modules and therefore ports may have to fall-back to inject the code in the surrounding module. This implies that support predicates used inside the test unit should not conflict with predicates of the module being tested.

9.1 PlUnit on SICStus

The directory of plunit.pl and swi.pl must be in the library search-path. With PLUNITDIR replaced accordingly, add the following into your .sicstusrc or sicstus.ini.

:- set_prolog_flag(language, iso). % for maximal compatibility
library_directory('PLUNITDIR').

The current version runs under SICStus 3. Open issues:

  • Some messages are unformatted because SICStus 3 reports all ISO errors as instantiation errors.

  • Only plunit.pl. Both coverage analysis and the test generation wizard currently require SWI-Prolog.

  • The load option normal is the same as always. Use set_test_options(load, never) to avoid loading the test suites.

  • The run option is not supported.

  • Tests are loaded into the enclosing module instead of a separate test module. This means that predicates in the test module must not conflict with the enclosing module, nor with other test modules loaded into the same module.