Vermeidung einer Neuverbindung zum Gerät

[xice]

Hallo,

ich habe folgendes Problem. An meinem PC ist ein Gerät über USB angeschlossen.
Das angeschlossene Gerät wird mittels JUnit Klassen getestet.

Dazu muss die Klasse eine Verbindung zum Gerät aufbauen. Diese Verbindung dauert recht lange.
Das heißt, immer wenn ein Test geändert oder neu ausgeführt wird, muss eine Verbindung zum Gerät aufgebaut werden.

Gibts hier Vorschläge bzw. Methoden, wie man die lästige Neuverbindung vermeiden lässt ?

Danke!

 

[Spacerat]

Eine Vermittlerklasse, die die Verbindung mit dem Gerät aufrecht hält und den Datenaustausch zwischen Unit und Gerät durchschleift. Die Unit kommuniziert dann nicht mit dem Gerät, sondern mit der Vermittlerklasse.
Manko: Die Unit-Tests werden durch fehlerhafte Implementation der Vermittlerklasse verfälscht.

 

[tribalup]

Dann vorher die Vermittlerklasse testen.

 

[xice]

Wie soll der Datenaustausch zwischen Unit und Gerät funktionieren ? Könntest du es evtl. ausfühlricher beschreiben.

 

[Spacerat]

Aus der Frage schliesse ich, dass dir das Prinzip einer Vermittlerklasse nicht wirklich geläufig ist. Die Unit kommuniziert nicht mit dem Gerät, sondern mit der Vermittlerklasse. Die Vermittlerklasse baut bei ihrer Instanzierung eine Verbindung zum Gerät auf und bei ihrer Zerstörung wieder ab (ein Fall für "finalize()" oder einem ShutDownHook). Verbindungsaufbau- und -abbauversuche der Unit zur Vermittlungstelle müssen von der Vermittlungsstelle protokolliert (also emuliert) werden, damit diese im Zweifelsfalle mitteilen kann, dass die Unit nicht verbunden ist, wenn sie Daten sendet. Der Datenaustauch sieht dann ungefähr so aus:
[c]Unit<->Vermittlungsklasse<->Gerät[/c]
Wie dass im einzelnen geht ist von deiner Schnittstelle abhängig.

 

[tfa]

Dann muss die "Vermittlerklasse" wohl auch auf einer eigenen VM, d.h. einem eigenen Prozess laufen, da die Verbindung ja nicht abreißen soll, wenn die Testklassen neu gestartet oder neu compiliert werden. Und wie läuft dann die Kommunikation mit dem Vermittler? Das Problem ist wohl nicht so einfach zu lösen.

 

[Spacerat]

Warum das denn? Bedeutet Testunit etwa immer nur das, was z.B. Eclipse als solche vorgibt? Muss für jede Testunit unbedingt immer 'ne neue JVM gestartet werden? Testunits feuert man doch eigentlich auf Schnittstellen ab, die in ihrer Gesamtheit ohnehin immer vorhanden sind. Da kann man doch recht einfach eine ganze Reihe von Units mit nur einem Start testen.

 

[tfa]

Wenn ich das richtig verstehe, dauert der Verbindungsaufbau oder die Initialisierung zu dem Gerät sehr lange. Und wenn du deine Testsuite beendest (weil du die Testfälle verändern willst z.B.), dann ist die Verbidnung weg und muss neu aufgebaut werden.

 

[tribalup]

Kommt drauf an warum die Verbindung so lange dauert. Kommt es vom hochfahren des Gerätes oder ist es die Anmeldeprozedur selber. Ist ersteres der Fall könnte ja einfach eine Verbindung durch pings etc. aufrechterhalten werden. Ist zweites der Fall wäre noch zu klären ob das Gerät selber progs ausführen kann bzw. freien Speicher für solche hat.

 

[xice]

Momentan ist der Ablauf folgendermaßen...
Eine Testsuite wird ausgeführt. Diese implementiert eine Klasse die für die Verbindung zum Gerät zuständig ist. Ein Testfall innerhalb dieser Testsuite prüft, ob bereits eine Verbindung besteht. Falls nicht -> Neuverbinden.

Wenn ich das richtig verstehe, dauert der Verbindungsaufbau oder die Initialisierung zu dem Gerät sehr lange. Und wenn du deine Testsuite beendest (weil du die Testfälle verändern willst z.B.), dann ist die Verbidnung weg und muss neu aufgebaut werden.

Genau.

 

[xice]

Kommt drauf an warum die Verbindung so lange dauert. Kommt es vom hochfahren des Gerätes oder ist es die Anmeldeprozedur selber. Ist ersteres der Fall könnte ja einfach eine Verbindung durch pings etc. aufrechterhalten werden. Ist zweites der Fall wäre noch zu klären ob das Gerät selber progs ausführen kann bzw. freien Speicher für solche hat.

Das Gerät ist bereits hochgefahren. Beim Verbinden werden Initialisierungen und einige checks durchgeführt.

 

[xice]

Würde dieser Ansatz funktionieren ?

Zwei JVM's, eine ist für die Verbindung des Geräts zuständig und enthält ein Interface zum Gerät. Das heißt muss nur einmal ausgeführt werden und ist immer aktiv.

Die andere nutzt das Interface und steuert das Gerät. Problem dabei ist die Kommunikation der beiden JVMs.

 

[Spacerat]

Also wenn das Gerät die Verbindung wegen Inaktivität trennt, dann muss die Vermittlungsstelle auf jeden Fall dafür sorgen, dass die Verbindung bestehen bleibt, solange keine Unit-Tests laufen. Und wenn man diese Tests auch noch unterbrechen will (oder sie das aufgrund eines Fehlers selbst tun), muss man entweder mit dem erneuten Verbindungsaufbau leben, oder wie tfa bereits angedeutet hat, die Vermittlerklasse in einem eigenen Thread laufen lassen. Wenn die Verbindung aber nur wegen der Initialisierungen so lange dauert, müssen diese ohnehin auch emuliert werden, was evtl. etwas schneller geht aber dann widerum auch die Testergebnisse verfälscht, wenn es um ConnectionTimeOuts geht. Deswegen ist die Frage, ob diese Aufrechterhaltung der Verbindung überhaupt sinnvoll ist.

 

[tfa]

Würde dieser Ansatz funktionieren ?

Zwei JVM's, eine ist für die Verbindung des Geräts zuständig und enthält ein Interface zum Gerät. Das heißt muss nur einmal ausgeführt werden und ist immer aktiv.

Die andere nutzt das Interface und steuert das Gerät. Problem dabei ist die Kommunikation der beiden JVMs.

Ja, so könnte man das machen. Für die Kommunikation könnte man RMI verwenden.
Nur so interessehalber: Wie lange dauert denn der Verbindungsaufbau zu dem Gerät?

 

[Ulic Quel-Droma]

Würde dieser Ansatz funktionieren ?

Zwei JVM's, eine ist für die Verbindung des Geräts zuständig und enthält ein Interface zum Gerät. Das heißt muss nur einmal ausgeführt werden und ist immer aktiv.

Die andere nutzt das Interface und steuert das Gerät. Problem dabei ist die Kommunikation der beiden JVMs.

Ich hab so was noch nie gemacht, aber eigentlich müsste das doch gehen:
1 JVM die sowohl das Interface enthält als auch die JUnit klassen enthält. Wenn man die JUnit klassen ändert lädt die JVM diese mit dem Classloader erneuert und ruft eine Test-methode auf, die halt in jeder Version JUnit Klassen vorhanden und gleich sein muss, auf.
Dann ist nur noch die Frage wie man diesen Prozess triggert. Dabei könnte vielleicht die JVM alle, sagen wir mal 30 sec überprüfen ob sich die JUnit klasse geändert hat und diese bei Änderung laden und den Testmethodenaufruf ausführen.

 

[xice]

Ja, so könnte man das machen. Für die Kommunikation könnte man RMI verwenden.
Nur so interessehalber: Wie lange dauert denn der Verbindungsaufbau zu dem Gerät?

Verbindungsdauer ca. 45 Sekunden.

So wie ich das verstanden habe, müssen bei Verwendung von RMI, die Klassen das Interface Serializeable implementieren. Da die genutzten Klassen dies nicht tun führt das zum Problem. Gibts da evtl. eine Alternative ?