OSGi tests

Setup, Configuration and Use Runtime
1

What is the correct way to run OSGi tests from IDE. In the end, I like add OSGi tests to my bindings, but currently I’m not able run OSGi test successfully for OH2 bindings which already have OSGi tests. Normal junit tests works fine.

When I try to run tests e.g. for max binding as a “Run as -> 7 JUnit tests” I got following error.

java.lang.AssertionError:
Expected: is not null
but: was null
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.junit.Assert.assertThat(Assert.java:865)
at org.junit.Assert.assertThat(Assert.java:832)
at org.junit.Assert$assertThat.callStatic(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:53)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:157)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:169)
at org.eclipse.smarthome.test.OSGiTest.bindBundleContext(OSGiTest.groovy:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

2

+1! Same here. It would be great to have a working setup in Eclipse and be able to run tests for the bindings.

3

You cannot run OSGi tests as plain JUnit tests as they require the OSGi framework to be started.
For this, you need to make sure that all required bundles are deployed on it as well, which can be tricky.

Usually, we have a launch configuration stored within the test bundle, which allows others to start the tests with the correct set of bundles. See e.g. https://github.com/openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.systeminfo.test/SysteminfoOSGiTest.launch.

You can find some further information on testing at
https://www.eclipse.org/smarthome/documentation/development/testing.html.

Maybe @svilenvul has some further hints as well as he is very eager in contributing tests.

4

Yes, I can only add a few thing to the Kai`s comment.

You could run the tests with “Run as -> JUnit Plug-in tests”.

Normally is not so easy, you have two pitfalls:

  1. This issue - https://github.com/openhab/openhab-distro/issues/230, which means that there is a conflict between the target platform and the Junit Plugin that runs the tests (unfortunately we could not fix this issue last time). I have a workaround, that is described in the issue, but for that you have to manually edit the target platform.
  2. The .lauch configurations include some bundles from the workspace and are not 100 percent portable. This means you would usually have to add some bundles manually.