State Machines mit Test-Driven Development in Embedded C bauen

State Machines sind fundamental für viele Embedded Systems, doch ihre Entwicklung kann komplex sein. Dieser Artikel skizziert bewährte Strategien für Building State-Machine (SM) Software using Test-Driven Development (TDD), mit Fokus auf C Implementierungen geeignet für ressourcenconstrained Environments.

Im Kern besteht ein SM Model aus States, Transitions und Actions. States repräsentieren Bedingungen, Transitions definieren den Pfad von einem State zum anderen – meist getriggert durch ein Event – und Actions erfassen das Behavior, ausgeführt während Entry, Exit oder während Transitioning.

In UML State Machines können Actions an State Entry/Exit, die Transition selbst oder Internal Reactions attached werden. Alle State-Machine Formalismen assumieren ein Run-To-Completion (RTC) Execution Model: Jedes Event wird fully processed – inklusive Exit Actions, Transition Actions und Entry Actions – bevor das nächste Event gehandhabt wird.

Bevor wir in TDD Strategies eintauchen, ist es essenziell zu verstehen, warum TDD matters. TDD ist ein inkrementeller Development Approach, der mandates, ein failing Unit Test vor jedem Production Code zu schreiben. Tests sind klein, automatisiert und dienen als Specification für desired Behavior. Der TDD Cycle – abgeleitet von James Grennings „Test-Driven Development for Embedded C“ – umfasst:

• Einen kleinen, failing Test schreiben.
• Alle Tests laufen lassen; der neue Test sollte failen.
• Minimalen Code schreiben, um den Test zu passen.
• Alle Tests erneut laufen lassen, um zu bestätigen, dass der neue Test passed.
• Refactoring zur Elimination Duplication und Improvement Clarity.

Betrachten Sie das SM Diagramm in Abbildung 1. Es beginnt in StateA und transitioned bei Empfang des Alpha Events zu StateB, executing xStateA(), effect() und nStateB() in Sequenz. Wie validieren wir, dass dieses Behavior korrekt ist?

Abbildung 1. Basic State Machine (Quelle: VortexMakes)

Der straightforwardeste Testing Approach involviert Verifikation der SM Transition Table. Dies erstellt einen Test Case pro State, stimuliert das SM mit relevanten Events und asserted resultierenden State und executed Actions. Complex Actions verdienen dedicated Tests. (Siehe Artikel „Testing state machines using unit test“ für in-depth Discussion.)

Jeder Test folgt dem Four-Phase xUnit Pattern:

• Setup – Preconditions etablieren (z. B. Current State, Event, Expected Target State, Action Sequence).
• Exercise – SM mit Event triggern.
• Verify – Outcomes gegen Expectations asserten.
• Cleanup – SM auf Initial State resetten (optional).

Während diese Strategie für simple SMs gut funktioniert, erfordert komplexeres Behavior – wie eine Kette von Transitions, wo ein Effect erst nach mehreren Steps observable ist – Functional Scenario Testing. Statt isolierter State Checks testen wir eine komplette Sequence, die notwendige States, Events und Actions exercised.

Abbildung 2 illustriert dies mit einem DoWhile SM, der einen traditionellen Do-While Loop mimict. Die Machine initialisiert mit Default Values via x = 0 und output = 0, setzt Loop Counter mit x++ oder x = (x > 0) ? x-: x, und iteriert mit i++ bis Guard i == x fails, woraufhin es output = i ausgibt.

Abbildung 2. Die DoWhile State Machine (Quelle: VortexMakes)

Vor Coding erstellen wir eine Test List derived from Specification. Für DoWhile umfasst die initiale Liste:

• All Data set to Defaults upon Initialization.
• Inkrementieren des X Attributes.
• Dekrementieren des X Attributes.
• Ausführen einer Single-Iteration Loop.
• Ausführen Multiple Iterations.
• Handling Non-Iterating Scenario.
• Checking Out-of-Bounds Conditions.

Wir employen Ceedling als Build System und Unity als Lightweight Test Harness für C Code. Das SM ist definiert in DoWhile.h und DoWhile.c, und die Test Suite residiert in test_DoWhile.c. Unten ein concise Excerpt illustrierend den „Single-Iteration“ Test Case.

Code Listing 1: Single Iteration Test (Quelle: VortexMakes)

Der Test initialisiert das SM, setzt Iteration Count auf Zero, dispatched Up Event zum Inkrementieren, triggert Start Event, und sendet schließlich Alpha um eine Loop Iteration auszuführen. Assertions verifizieren, dass out Attribute der Iterationsanzahl gleich ist und das SM in StateC verbleibt.

Erweitern desselben Tests demonstriert Multiple Iterations (siehe Code Listing 2). Ein separater Test (Listing 3) bestätigt, dass das SM keine Iterationen performt, wenn Alpha ohne vorheriges Up Event empfangen wird.

Code Listing 2: Multiple Iteration Test (Quelle: VortexMakes)

Code Listing 3: Non-Iteration Test (Quelle: VortexMakes)

Implementation Details sind nicht Fokus dieses Artikels, aber Excerpts aus DoWhile.c und DoWhile.h illustrieren einen clean Switch-Case Approach zu State Handling.

Code Listing 4: Fragment of DoWhile Implementation (Quelle: VortexMakes)

Code Listing 5: Fragment of DoWhile Specification (Quelle: VortexMakes)

Zusammenfassend bietet TDD zwei komplementäre Strategien für State-Machine Development: (1) State-by-State Transition Testing, und (2) Functional Scenario Testing, das Multiple States und Actions abdeckt. Diese Methoden sind Language-agnostic, Tool-agnostic und besonders gut geeignet für Embedded Systems, wo State-Based Logic dominiert.

Da C die Lingua Franca Embedded Software bleibt, yields pairing mit Ceedling und Unity einen robusten TDD Workflow. Adopting diese Practices führt zu Software, die flexibler, maintainable und reusable ist als konventionelle Approaches.

All Code und Models sind im GitHub Repository https://github.com/leanfrancucci/sm-tdd.git verfügbar.