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

```bash

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= ./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.