Replies: 3 comments 12 replies
-
I think you can look to the osgi-test project for an OSGi recommended way to test OSGi code. If fact we use osgi-test in the OSGi TCKs. |
Beta Was this translation helpful? Give feedback.
-
This is not something the specs should have. The OSGi specs are for runtime. We should not spec how we build and test things. We can certainly document (not in a spec) how we build and test things. |
Beta Was this translation helpful? Give feedback.
-
|
| The OSGi specs are for runtime. Mostly yes, but our Annotations describe what a build tool should do with it. It thus describes something, that has no influence at runtime. I also don't see where we describe what influence e.g. the specified Header |
Beta Was this translation helpful? Give feedback.
-
Well in the last spec call is was argued that a TCK must "run in a real OSGi Framework" so actually the tests are executed at runtime... But how do I "really run" them if running tests is nowhere specified? So for me this is nothing one can really separate as not runtime-related... |
Beta Was this translation helpful? Give feedback.
-
That is not true. Of course the annotation cause the tool to generate information which is then used at runtime. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if arguing about the definitions of "runtime" helps, there are actually sometime "concepts" described in the spec e.g.:
that are "not enforced at runtime" and therefore, strictly speaking, not relevant for the runtime. And as described at the bottom of my idea, of course one could think about having a running OSGi-Framework and then deploy a "Test-Bundle" and having some Agent execute it and report back results... one even can think about having the TCKs deployed and having such a service check the impls first before allow the bundle to be seen by others so if one just want to enforce some "runtime aspect" I'm sure one can find some :-) E.g. the Eclipse-Test-Framework works that way that the is a Eclipse-Osgi-Framework running and you deploy test-bundles into it that runs acceptance test for different platforms without recompile the code or even have a certain build tool! |
Beta Was this translation helpful? Give feedback.
-
|
I would vote raising this to an issue and to discuss this in the next spec call. |
Beta Was this translation helpful? Give feedback.
-
|
@juergen-albert I think discussions can be discussed in the spec call as well, but you probably want to add a label to it (I think only collaborators of the repository can add labels). |
Beta Was this translation helpful? Give feedback.
-
|
not sure what kind of lable I should give it. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
For example https://bnd.bndtools.org/chapters/310-testing.html already has some kind of "specification" of how test are run in a runtime see section "Testing With JUnit 5 - biz.aQute.tester.junit-platform":
|
Beta Was this translation helpful? Give feedback.
-
When talking to others, the most unclear part for people about OSGi often is:
Of course there are multiple ways and different levels and some approaches, but all of them lack one important part: There is no common specification / definition so I can't exchange them and there is no common base even many of them share similar concepts.
Here are some examples:
All of them has (in some way or the other) some way to identify test, fire up a framework, and then use a "test-provider" to execute the test-cases, but of course I can't just share one bundle used for bnd with one from pax or tycho or ...
I therefore think it would be good to have a very basic "Test-Bundle-Specification" that tools can leverage to give users a guidance how they should "shape" their test-bundles so they can be executed by compatible tools.
As a first start, I think these minimal definitions would give a good starting point for a first spec-draft that might be build upon then:
Test-Casesheader what seems suitable and flexible enough for a generic definitionTest-Provider-CapabilityIf that's done, it would be great to also define how a compliant test execution could/should work e.g.
TestExecutorServicewhere one can trigger tests?Beta Was this translation helpful? Give feedback.
All reactions