Testing and CI
Testing & CI for Device Software
Test strategy and CI structure for embedded device software, service layers, REST APIs, MQTT communication and browser-based service interfaces.
The goal is not abstract test coverage. The goal is safer change in existing device software: fewer integration surprises, faster diagnostics, reproducible builds and better confidence when modifying legacy systems.
Why testing matters in device modernization
Existing device software often contains hardware dependencies, long-lived C/C++ code, undocumented assumptions and tightly coupled UI or service logic. Introducing automated tests and CI in such systems requires a practical, incremental approach.
Safer changes
Automated tests help reduce the risk of breaking existing device behaviour during refactoring and modernization.
Better integration feedback
CI pipelines expose build, test and integration problems earlier, before they reach device bring-up or field testing.
More maintainable releases
Reproducible builds, versioned artifacts and documented test scope make releases easier to control and support.
Testing areas
Unit tests
Tests for device logic, validation rules, state handling, configuration processing and service layer behaviour.
Mock hardware interfaces
Abstractions for testing software behaviour without requiring full hardware access for every test run.
API tests
REST endpoint behaviour, error handling, versioning and contract stability.
MQTT tests
Topic structure, payload validation, event behaviour and connection handling.
Integration tests
Service layer, device communication, UI backend and selected hardware or simulator-based workflows.
GUI smoke tests
Basic checks for browser-based service UI workflows, status display and critical service screens.
CI pipeline structure
- Build: reproducible builds for relevant components such as firmware, C/C++ services, Node.js runtime and browser UI.
- Static checks: code quality checks, linting, formatting or static analysis depending on the technology stack.
- Automated tests: unit tests, API tests, selected integration tests and service layer checks.
- Artifacts and releases: versioned artifacts, update packages, release notes and documentation outputs where useful.
Typical CI stages
| Stage | Purpose |
|---|---|
| Source checks | Basic validation, formatting, linting and consistency checks before deeper testing. |
| C/C++ build | Build embedded services, device communication components and test binaries. |
| Frontend build | Build browser-based UI components and verify dependency consistency. |
| Unit tests | Run tests for isolated logic, service functions, validation rules and state handling. |
| API tests | Check REST API behaviour, response structure, error handling and contract stability. |
| MQTT tests | Validate topic structure, message payloads and event publication behaviour. |
| Artifacts | Create versioned binaries, packages, UI builds, documentation or update bundles. |
Legacy system approach
Many device software platforms were not originally designed for automated tests. In that case, the practical path is incremental: introduce interfaces, isolate critical logic, add mocks around hardware communication and build tests around areas that change frequently or create integration risk.
Start with high-risk areas
- Configuration validation
- Command routing
- Device state transitions
- Error handling
- Update and version logic
Introduce test seams
- Hardware abstraction interfaces
- Mock device communication
- Service layer boundaries
- API-level tests
- Simulation or test-mode components
Mocking hardware dependencies
Hardware-dependent software cannot always be tested directly in a normal CI environment. Mock interfaces and simulator-like components make it possible to test command handling, state logic, API behaviour and error cases without requiring physical hardware for every build.
| Dependency | Possible test approach |
|---|---|
| Serial, CAN, USB or Ethernet communication | Mock transport layer, recorded message sequences or test adapters. |
| Device state and subsystem readiness | Simulated state provider or mocked hardware abstraction. |
| Error and warning conditions | Injected faults, invalid responses and timeout scenarios. |
| Configuration storage | Test configuration backend, temporary files or isolated data stores. |
Testing REST APIs
REST API tests check whether the device service layer behaves as expected from the perspective of a browser UI, service tool or external integration system.
- Endpoint availability
- Request validation
- Response structure
- Error model
- Version compatibility
- Authentication and access assumptions where applicable
- Behaviour under invalid or unexpected device states
Testing MQTT communication
MQTT tests are useful when the device publishes telemetry, status updates, warnings, service events or diagnostic information. The tests should focus on topic structure, payload consistency and behaviour during state changes.
- Topic naming and structure
- Payload schema and required fields
- Status and telemetry separation
- Event publication on state changes
- Reconnect and communication error behaviour
- Compatibility with service tools or monitoring systems
Documentation of test scope
For existing device software, it is important to document what automated tests cover and what still requires hardware-in-the-loop testing, manual lab validation or field verification. This avoids false confidence and supports realistic release planning.
Deliverables
- Test strategy for existing device software
- Unit test structure for selected components
- Mock interfaces for hardware-related dependencies
- REST API and MQTT communication tests
- CI pipeline setup or improvement
- Build and release artifact structure
- Documentation of test scope and limitations
- Integration with release and update workflows
Reduce the risk of changing existing device software
I support practical test and CI structures for embedded device software, service layers, APIs and browser-based service interfaces.