Test-driven Development - Erstellung eines Systemtests

lostify

Grünschnabel
Moinsen,
meine Frage bezieht sich auf die theoretische Gestaltung eines automatisierten Systemtests.

Nehmen wir einmal an, dass ich eine Software entwickeln möchte, die über kein eigenes Framework verfügt und nur aus wenigen Klassen besteht, wovon eine für die Kommunikation über eine dedizierte COM-Schnittstelle verantwortlich ist und je nach Methodenaufruf verschiedene Befehle über die Schnittstelle dem anderen Teilnehmer mitteilt (schreiben und lesen von Daten).


Würde ein Framework die Kommunikation nach außen übernehmen, könnte ich relativ einfach ein Testframework erstellen und die entsprechende Softwarekomponente mit den Proxydaten des Testframeworks initialisieren. Somit würde ich jegliche Kommunikation der Komponente abgreifen und entsprechend der Testvorgaben auswerten können.

Mein Dilemma besteht nun darin, das ich keine wirkliche Vorstellung darüber habe, wie man die COM-Schnittstelle auf das Testprogramm umlenken kann, ohne in der eigentlichen Software eine zu große Änderung zu machen oder das System mit virtuellen COM-Brücken zuzumüllen.

Mein generelles Vorgehen wäre, aus der Software keine ausführbare Datei zu machen, sondern die zu testenden Klassen als DLL-Export zu deklarieren und eine entsprechende DLL zu kompilieren. Hiermit könnte ich die internen Klassen ohne Probleme testen, jedoch nicht die, die über Hardware-Schnittstellen kommunizieren möchten.

Deshalb nun meine Frage: Ist es generell möglich Klassen automatisiert zu testen, die über die Hardware-Schnittstellen ihren Dienst verrichten sollen? Wenn nein, ist es vielleicht empfehlenswert die entsprechende Klasse zu unterteilen, sodass eine reine Kommunikationsklasse vorliegt, die einzig und allein einen übergebenen Befehl an die entsprechende Schnittstelle weitergibt und den empfangenen Rückgabewert zurückgibt, oder ist es sinnvoller das zusammensetzen der Befehle mit in eben dieser Klasse zu lagern?
Kann man eine solche Kommunikation nach außen vielleicht nur händisch überprüfen? Diese Annahme würde eher zu einer unterteilten Klassenstruktur führen, bei der die Befehlszusammensetzung in eine eigene - dann besser testbare - Klasse ausgelagert werden würde.


Ihr seht, Fragen über Fragen wegen einem kleinen Testszenario.
Zur Verdeutlichung: Mir geht es nicht um einen konkreten Lösungsweg, sondern viel eher um die Theorie dahinter, wie etwas getestet werden kann, das eine Hardwareansteuerung übernimmt.

Da es hier um Hardware geht sollte gesagt sein, dass es sich um ein Windows-Betriebssystem handelt und dementsprechend keine direkte Kontrolle der Hardware möglich ist.


Mit freundlichen Grüßen,
lostify
 

saftmeister

Nutze den Saft!
Wenn ich deine Frage richtig verstanden habe, suchst du nach einer Möglichkeit, eine serielle Schnittstelle zu mocken? Dann könnte das hier für dich interessant sein:

http://com0com.sourceforge.net/

Damit könntest du ein virtuelles Gerät an der seriellen Schnittstelle registrieren, was dann genau das zurück gibt, was du ihm mitteilst. Allerdings wäre dann erforderlich, ein solches virtuelles Gerät zu programmieren. Also quasi die Gegenstelle zu deiner Anwendungssoftware. Aber wer garantiert, dass dann in dem virtuellen Gerät kein Software-Fehler ist ;-)

Aber du schreibst ohnehin "Systemtest" und nicht "Komponententest". Ein Systemtest findet idR. End-to-End statt und wird somit manuell ausgeführt.