[...] make check-TESTS make[2]: Entering directory `/home/stigge/elektronik/hellotest/tests’ Test running on targetdev... PASS: test-test Function Tests ..... OK 5 succeeded 10.655778 s (655778 us) total elapsed time PASS: test-functions Static Tests .. OK 2 succeeded 2.210588 s (210588 us) total elapsed time PASS: test-static Library Tests ..... OK 5 succeeded 0.006428 s (6428 us) total elapsed time Stress Tests (100 iterations) (1).....(6).....(11).....(16).....(21).....(26).....(31).....(36).....(41).....(46).....(51).....(56).....(61).....(66).....(71).....(76).....(81).....(86).....(91).....(96)..... OK 5 succeeded 0.878457 s (878457 us) total elapsed time PASS: test-library ================== All 4 tests passed ================== make[2]: Leaving directory `/home/stigge/elektronik/hellotest/tests’ [...]

Listing 4. Bildschirmausgabe bei erfolgreichem Durchlauf von make check.

Test-Code häufig umfangreicher als Produktiv-Code

Da jedes Embedded-Projekt sehr individuelle Randbedingungen aufweist, müssen die beschriebene Test-Umgebung und einige Ideen für jedes Projekt individuell modifiziert werden. Der Aufbau einer zweckmäßigen Testumgebung ist naturgemäß eine der schwierigsten Aufgaben beim Schreiben neuer Tests. Darüber hinaus sollte man nicht vergessen, dass Unit-Tests nicht an eine spezielle Implementierung eines Unit-Test-Frameworks wie autounit gebunden sind oder an eine besondere Sprache. Qualitätssicherung ist nicht allein damit erreicht, dass Unit-Tests in den Entwicklungsprozess eingebunden werden.

Das Wichtigste beim Unit-Testen ist: es zu tun! Zudem ist es sehr dringend angeraten, möglichst frühzeitig im Entwicklungsprozess damit anzufangen. Unit-Tests können eine drastische Verbesserung der Vorhersehbarkeit von Entwicklungsplänen bringen, weil sie die Zeit, die für das Debugging benötigt wird, massiv senken können. Dennoch sollte man auch immer den Umfang des erforderlichen Test- Codes berücksichtigen, der häufig deutlich größer ist als der zu testende Code. jk

Roland Stigge studierte Informatik an der Humboldt-Universität in Berlin und ist heute Software-Entwickler bei der Philosys Software GmbH in Unterschleißheim bei München. Er ist zugleich Debian-Entwickler und GNU-Maintainer und verfügt über umfangreiche Erfahrungen in weit verbreitet genutzten Open-Source-Betriebssystemen. Sein Hauptinteresse gilt der Embedded-Software-Entwicklung mit den Schwerpunkten Qualitätssicherung, Open- Source-Software und Linux-/Unix-Betriebssysteme. roland.stigge@philosys.de

Verwandte Artikel:

Prozessoren umkrempeln

Eclipse intim