TDD und Mikrocontroller: ein praxistauglicher Test-First-Ansatz​

Inhaltsverzeichnis

Bei dem von Kent Beck eingeführten [1] Test-Driven Development (TDD) schreiben Entwicklerinnen oder Entwickler erst einen Test und beginnen anschließend mit der Implementierung. Der Test ermöglicht es, die Codequalität der Anwendung zu optimieren. TDD bietet in der Softwareentwicklung für Mikrocontroller Potential. Wer darauf setzen möchte, sollte die Idee zunächst verstehen und sie anschließend an die spezifischen Bedingungen von Embedded-Systemen anpassen.

Die Kernidee von TDD liegt darin, Tests zu nutzen, damit sie während der Entwicklung die Feedbackschleife erheblich verkürzen, also die Zeit, um eine Aufgabe auszuführen und zu überprüfen, ob sie erfolgreich war. Dadurch werden Tests zu einem wesentlichen Entwicklungswerkzeug und nicht nur zu einem Tool für die Qualitätssicherung.

TDD ist als Methode weder an eine Programmiersprache noch an eine Umgebung gebunden. Allerdings sollte es vorab möglich sein, Tests einfach zu erstellen und zügig durchzuführen. In der Praxis sollten alle relevanten Tests in etwa zehn Sekunden erledigt sein.

Feedback bei der klassischen Softwareentwicklung

Bei der Entwicklung von Desktopsoftware können Developer Code testen, indem sie entweder das gesamte Programm oder einzelne Funktionen mithilfe von Unit-Tests ausführen. Das komplette Programm zu testen, ist unkompliziert und benötigt keine spezielle Vorbereitung.

Je umfangreicher das Programm ist, desto mehr Zeit ist erforderlich, um den zu testenden Codeabschnitt zu erreichen. Daher verlängert sich die Feedbackschleife, wenn das Projekt wächst. Bei nichttrivialen Projekten dauert es mindestens einige Minuten, um zu kompilieren, die Anwendung zu starten, die erforderlichen Einstellungen oder Eingabewerte vorzunehmen und die Ergebnisse zu überprüfen. Zwischen der Implementierung einer Codeänderung und der Überprüfung, ob sie wie beabsichtigt funktioniert, vergehen jedes Mal wertvolle Minuten in der Feedbackschleife. Diese Zeit steht nicht mehr für andere produktive Aufgaben zur Verfügung.

Die iX-Konferenz zur Entwicklung für das IoT

Am 21. und 22. Februar findet in München die building IoT 2024 statt. Die von iX und dpunkt.verlag ausgerichtete Konferenz richtet sich an diejenigen, die Anwendungen und Produkte für das Internet der Dinge erstellen. Dieses Jahr stehen die Themen IIoT und KI besonders im Fokus.

Das Programm bietet an zwei Tagen gut 30 Vorträge in drei Tracks unter anderem zu Unified Namespaces, KI auf MCUs, Cyber Resilience, niedriger Stromverbrauch von Embedded-Geräten und Data Science in der IoT-Entwicklung.

Unit-Tests sind darauf ausgelegt, isolierte Teile des Codes zu prüfen. Einen Unit-Test durchzuführen, nimmt nur wenige Sekunden in Anspruch und verkürzt die Feedbackschleife deutlich. Die Software muss jedoch passend eingerichtet sein. Der zu testende Code sollte beispielsweise nicht von externen Ressourcen wie einer Datenbank oder einer Benutzeroberfläche abhängig sein. Das Entkoppeln verbessert meist die Codequalität, ist aber zeitaufwendig. Für Teams, die zum ersten Mal Unit-Tests verwenden, kann die Umstellung eine Herausforderung sein. Glücklicherweise ist es heutzutage gängige Praxis, bei allen nichttrivialen Projekten ausgiebig Unit-Tests einzusetzen.

Feedback bei der Embedded-Entwicklung

Embedded-Entwicklung kann hinsichtlich des Testens überwältigend und frustrierend sein. Embedded-Programme laufen nicht einfach auf dem Entwicklungs-PC, sondern das Programm liegt als Binärdatei vor und erfordert die Zielhardware. Um die Anwendung zu flashen, ist eine separate Programmierer/Debugger-Hardware erforderlich. Um den relevanten Code auszuführen, muss man potenziell einige Werte eingeben, etwa durch das Senden von CAN-Frames (Controller Area Network), die Kommunikation über ein serielles Terminal oder das Anschließen eines spezifischen Sensors. Die Feedbackschleife für ein eingebettetes Projekt ist daher von Haus aus deutlich länger und führt zusätzlich zu einer Abhängigkeit von spezifischer Hardware. Dual-Targeting ermöglicht jedoch die sinnvolle Verwendung von Unit-Tests in der Embedded-Entwicklung.