Junit Plug-In Test

[nodder]

Hallo zusammen,

entweder hab ich nen grundlegendes Verständnisproblem oder ich bin einfach blind. Seit zwei Tagen suche ich ne Lösung, finde aber einfach keinen Ansatz.

Ich habe hier eine recht umfangreiche OSGi Server Applikation mit Dutzenden Services. Jetzt habe ich ein weiteres Plug-In Projekt implementiert, welches ich gerne im OSGi Kontext testen möchte.

Also habe ich eine JUnit-Tesklasse erzeugt, die ich als Plug-In Test laufen lasse. Target Platform und Plugin dependencies soweit eingerichtet, dass der löuft. Soweit so gut. Aber wie komme ich denn jetz in der Testklasse an die Services bzw. den BundleContext heran um dann meinen neuen Service zu testen?

Das ist doch irgendwie der grundlegende Schritt, aber ich finde einfach nicht raus, wie es geht. Auch wenn ich den Test in einem separaten Fragment Project habe, komme ich da nicht ran.

Wo ist mein Denkefehler?

Danke schonmal im Voraus.

Beste Grüße

 

[Gast2]

http://www.java-forum.org/plattformprogrammierung/99859-osgi-bundle-testen-junit4.html

Chapter 11. Testing OSGi based Applications

 

[nodder]

Danke schonmal für den Hinweis.
Diese beiden (und viele andere) Beiträge habe ich in der Tat auch schon gefunden, sie helfen mir allerdings nicht wirklich weiter.

http://www.java-forum.org/plattformprogrammierung/99859-osgi-bundle-testen-junit4.html

Da wird das Thema leider nicht wirklich zu Ende diskutiert. Irgendwelche Erweiterungen und andere Frameworks wollte ich nicht unbedingt anfassen, wenn es sich vermeiden lässt. Es geht mir auch vorerst nicht um Intergration, sondern um's alleinige Testen in meiner Entwicklungsumgebung.

'Wildcard' erwähnt in Antwort #5 folgendes:

2. PlugIn Unit Test
Wenn Variante 1 bei dir kein gangbarer Weg ist, bleiben PlugIn Unit Tests. Diese Tests werden tatsächlich in einer OSGi Umgebung ausgeführt, es existiert also ein BundleContext über den du Services beziehen kannst.

Genau diesen BundleContext suche ich. Wo ist der? Wie komme ich dran? Ich hab in dem Test ja keinen Activator...

Chapter*11.*Testing OSGi based Applications

Auch hier wird irgendwie nur beschrieben, wie ich die Services mocken kann... Dafür muss ich sie aber erst mal haben und da fängt mein Problem schon an.

Vielen Dank schonmal.
Besten Gruß

 

[maki]

. Aber wie komme ich denn jetz in der Testklasse an die Services bzw. den BundleContext heran um dann meinen neuen Service zu testen?

So wie in einem nicht-Test-Plugin auch?
k.A. was du verwendest (DS, etc.), aber eben so wie du es in den normnalen Plugins auch machst.
Vorraussetzung ist eben dass du ein rchtiges Plugin hast, kein Fragement.

Mit Tests in Fragementen kann man innerhalb eines Plugins testen, andere Services (also von "aussen") testen man mit Plguins.

 

[Gast2]

Genau diesen BundleContext suche ich. Wo ist der? Wie komme ich dran? Ich hab in dem Test ja keinen Activator...

Klar hast du einen Activator... Dein TestBundle ist ein ganz normales OSGI-Bundle, sonst klappt es nicht

 

[nodder]

Ha,

seht ihr, da war schonmal mein Grundlegendes Verständnisproblem. Ich bin immer von Fragment-Bundles ausgegangen... ;-) Vielen Dank schonmal dafür.

Dann müsste ich doch auch eigentlich die Tests einfach im Original Bundle liegen lassen können, oder?!
So hatte ich nämlich ursprünglich angefangen. Einfach ein weiteren src-Folder 'test' mit den Tests. Wenn ich die Tests dann aber starte (Run as JUnit Plug-In Test), passiert leider nicht viel. Der Test schlägt fehl, das OSGi Framework scheint nicht hochgefahren zu werden. Zumindest wird der Activator nicht aufgerufen. In der Run Configuration habe ich alle benötigten Bundles ausgewählt...

Wenn ich ein separates Bundle nur mit den Tests mache, krieg' ich nen NoClassDefFoundError auf TestCase...

Aber ich meine zu beiden Problemen schonmal was gelesen zu haben. Dann recherchier ich mal in der Richtung weiter.

Beste Grüße

 

[maki]

Dann müsste ich doch auch eigentlich die Tests einfach im Original Bundle liegen lassen können, oder?!

Böses Foul, die schlechteste von allen möglichen Varianten, lass das lieber..

Wenn ich ein separates Bundle nur mit den Tests mache, krieg' ich nen NoClassDefFoundError auf TestCase...

JUnit etc. müssen halt da sein, im OSGi Sinne (Require-Bundle bzw. import Package).

 

[nodder]

So, ich komme der Sache seeeeeehr viel näher.

Was jetzt noch ein Problem zu sein scheint:
Ich muss in allen Bundles
Bundle-ActivationPolicy: lazy
aktivieren. Sonst kann das Test Plug-In die Bundles nicht starten. Das will ich jetzt aber irgendwie nicht für 100 Bundles machen. Darf aus verschiedenen Gründen auch nicht gemacht werden.

Wie kann ich das umgehen?

Grüße

 

[maki]

IMO sollte die Bundle-ActivationPolicy immer lazy sein bei Eclipse RCP Plugins.

Was sind denn die deine/eure Gründe für Eager?

 

[nodder]

Der Server soll halt direkt einsatzfähig sein. Die genauen Details würden da jetzt zu weit führen.

Ist doch aber auch eigenartig, eigentlich müsste doch mit unserer Einstellung noch eher gewährleistet sein, dass die Bundles laufen...

 

[maki]

Nö, ist sehr unüblich, deutet IMHO auf eine nicht so gute OSGi Runtime Konfig hin, bei Equinox die config.ini.
In dieser kann man nämlich eintragen, wann welches Bundle gestartet werden soll.

Von Eager auf Lazy zu wechseln in den Manifesten ist eine Sache von Search&Replace und dauert Sekunden, aber das Programm umzustricken ist aufwendiger.
Würde dir/euch aber trotzdem empfehlen das zu machen, IMHO ist da was faul.

 

[nodder]

Wie gesagt, wir wollen halt verhindern, dass die Bundles erst bei den ersten Requests anlaufen. Da sind einige bei, die ein paar Sekunden zum start brauchen. Und bei der Masse an Bundles kann das unangenehme Effekte haben. Zumal es ja kein Nachteil sein kann. Früher oder später laufen dann eh alle Bundles, dann kann ich das auch gleich zu Beginn forcieren.

Naja, dann werde ich das für Testzwecke halt manuell umstellen müssen.

Wobei sich mir nicht erschließt, warum sich die Bundles in dem Testkontext nicht nicht starten lassen. Eager sollte doch dafür sorgen, dass sie auf jeden Fall längst angelaufen sind...

 

[maki]

Wie gesagt, wir wollen halt verhindern, dass die Bundles erst bei den ersten Requests anlaufen. Da sind einige bei, die ein paar Sekunden zum start brauchen. Und bei der Masse an Bundles kann das unangenehme Effekte haben. Zumal es ja kein Nachteil sein kann. Früher oder später laufen dann eh alle Bundles, dann kann ich das auch gleich zu Beginn forcieren.

Dann macht das in der config.ini (für Equinox)!

 

[nodder]

Versteh mich nicht falsch,
aber ich werde jetzt nicht so ohne weiteres die Start-Policy für eine Applikation mit 150 Bundles ändern, die sich in den letzte fünf Jahren als funktionierend herausgestellt hat nur mein Test-Bundle ans laufen zu kriegen. Dann bringt mich unsere QA um. Es mag sein, dass das besser ist. Aber diese Entscheidungen wurden getroffen, weit bevor ich die Software angefasst habe.

Vielen Dank für den Hinweis, dass das anders vielleicht besser wäre. Aber das ist nichts, was wir jetzt einfach so über's Knie brechen.

Falls also einer eine Idee hat, wie auch "nicht-lazy" bundles über die Tests starten kann, wäre ich sehr dankbar.

Beste Grüße