Skip to content

Integration Testing

Integration tests validate KLAS end-to-end: a real binary is started, real MQTT messages are exchanged through a RabbitMQ broker, and firmware downloads are served from an HTTPS file server.

Tests are written with Pluma and live in the integration-tests/ directory.

Directory layout

integration-tests/
├── certs/               # TLS certificates for MQTT broker and HTTP server
│   ├── certificates/    # Client/leaf certs used by KLAS
│   └── rmq-*.{crt,key}  # RabbitMQ TLS cert/key pair
├── config/
│   ├── config.json              # KLAS runtime config (points to integration services)
│   └── config-provisioning.json # MQTT provisioning config (login/password mode)
├── http-server/
│   ├── Caddyfile        # Caddy HTTPS server config
│   ├── Dockerfile       # File server image definition
│   └── files/           # Files served over HTTPS (e.g. sample_os_file.txt)
└── pluma/
    ├── pluma.yml        # Top-level plan: includes all test groups via !include
    ├── target.yml       # MQTT resource configuration for Pluma
    ├── common/
    │   ├── start-klas.yml   # Shared helper: clears cache/dl, starts KameaLinuxAgent
    │   └── stop-klas.yml    # Shared helper: stops KameaLinuxAgent
    └── firmware-update/
        ├── simple-update.yml            # Basic download + install confirmation
        ├── no-download-update.yml       # Version announced but download not triggered
        ├── multi-firmware-update.yml    # Multiple firmware types updated together
        ├── two-versions-sequential.yml  # Two versions announced sequentially, one installed
        ├── two-versions-update-last.yml # Latest version downloaded when two exist
        ├── two-versions-update-both.yml # Both versions downloaded independently
        ├── failed-download.yml          # Bad URL triggers failedFirmwareDownloads
        ├── restart-persistence.yml      # Cache survives KLAS restart
        ├── idempotent-desired-config.yml# Duplicate desired config has no side effects
        ├── invalid-firmware-args.yml    # Invalid name/version rejected with D-Bus error
        └── dbus-signals.yml             # newFirmwareVersionsAvailable, newFirmwareFilesDownloaded, newFirmwareDownloadFailed signals verified

Services

Service Alias in CI Purpose
RabbitMQ rabbitmq MQTT broker with TLS on port 8883
HTTPS server file-server Serves firmware artefacts over HTTPS (Caddy)

Configuration

integration-tests/config/config.json

Key fields used for integration tests:

Field Value
cache-storage-path cache_storage.json
http-trust-store certs
log-level Debug

integration-tests/config/config-provisioning.json

Connects to RabbitMQ using login/password authentication over MQTT TLS:

Field Value
hostname rabbitmq
port 8883
mode login-password
trust-store certs/rmq-root-ca.crt

Running locally

A helper script, dev-tools/run-integration-tests.sh, replicates the CI integration-test stage on your machine. Everything runs inside Docker — you do not need to install Pluma or build KLAS locally.

Prerequisites

  • Docker installed and running
  • The klas-devtools image built or pulled (see CI/CD)
  • The RabbitMQ (kamea-rmq-test-e2e) and file-server images pulled

Usage

# Use the default registry (registry.gitlab.com/witekio/rnd/b0000-theembeddedkit-klas/klas)
./dev-tools/run-integration-tests.sh

# Or point to a different registry
CI_REGISTRY_IMAGE=<your-registry> ./dev-tools/run-integration-tests.sh

D-Bus interfaces used by tests

The integration tests use busctl to interact with the Firmware D-Bus interface.

The D-Bus policy (libraries/extcom/dbus/com.witekio.klas.conf) allows org.freedesktop.DBus.Properties and org.freedesktop.DBus.Introspectable in addition to the KLAS-specific interfaces, which is required for busctl get-property to work.