Skip to content

Automated Testing

WissKI includes several automated tests to ensure that WissKI functionality remains intact. phpunit is used to implement and run these automated tests. They are configured using phpunit.xml.dist, which also configures various required environment variables.

They can be run inside the devcontainer using phpunit .. They are run on CI using the PHPUnit job.

Overview & Infrastructure

All tests are located inside the wisski_core/tests folder. Despite being in the wisski_core module folder, they test all WissKI modules. This choice condenses all test code into a single source location.

The tests specifically make use of a real triplestore. They also require a controllable HTTP server that is reachable from the testing environment. The tests expect the following two components:

  1. An RDF4J Instance to dynamically create triplestore repositories on demand. We make use of the RD4J Rest API to create transient in-memory triplestores.
  2. A web server to serve static files. This is a custom go server, that supports placing files using the PUT and DELETE methods. It's source code can be found at github.com/FAU-CDI/static_test_server). All data is transient, and only held in memory.

Both are configured using environment variables inside the phpunit configuration file. By default, RDF4J is expected to run on http://rdf4j:8080/rdf4j-server/ and the static webserver is expected to be reachable at http://static:8888. There should be no need to re-configure these, as both are available automatically both in CI and the devcontainer.

Test Structure & the wisski_test module

The tests split into two categories: - Functional Tests. - Functional JavaScript Tests

These live in the Functional and FunctionalJavascript directories, respectively. For testing purposes the wisski_test module exists. It contains utility code needed for supporting the tests.

Functional tests parts of WissKI which do not require any JavaScript to run. Functional Javascript tests may test functions that require JavaScript. At minimum, this is anything that requires Ajax. Functional Javascript tests are a lot slower to run that functional tests, therefore new tests should prefer not to require JavaScript.

Tests extend their corresponding base classes:

  • \Drupal\wisski_test\WisskiFunctionalTestBase for functional tests; and
  • \Drupal\wisski_test\WisskiJavascriptTestBase for functional javascript tests.

These each setup a blank Drupal for testing, enabling all WissKI and related modules, and perform additional setup.

Writing your own Tests

(to be documented)

Debugging tests

A specific helper trait ensures that it is also possible to debug the tests inside the devcontainer. Specifically, the XDEBUG_TRIGGER environment variable is automatically forwarded to any running test code.

It is therefore possible to trigger XDEBUG with something like:

XDEBUG_TRIGGER=1 phpunit .