Daniel Fagerstrom wrote:
Don't wait on that, I'm not clear about it my self ;)
The idea is that I would assume that when we test a block it is best
to do it in an environment that is as close as possible to the
environment it will be used in. For an OSGi bundle this means that it
will get access to external packages through the OSGi classloader
functionality and also that it might need some external services (that
we might have mock implementations of).
One way of handling this is to run the tests within an OSGi framework,
but this give problems. Either the unit tests are in a separate
bundle, but then only methods in classes in exported packages can be
tested. That is certainly not what we want.
Or we have the tests within the bundle, now everything can be tested,
but we need export some service that run the tests instead and have
some mechanism that remove both this service and the tests for
production use. This seem like a clumsy and intrusive solution.
I guess that the conclusion is that it not is a good idea to do unit
testing in an ordinary OSGi framework. A solution could be to have a
special test OSGi framework with limited functionality, like our test
containers for Avalon components. Felix and Eclipse will probably have
the same problem, so we can move the question to e.g. the Felix list
when we need a solution.
For now, don't care about OSGi for the tests, we can solve that later.
/Daniel
I don't think you have as much to worry about as you think you do.
Build a block will probably involve building a jar and then doing some
stuff to build the block. When maven runs unit tests it can test
against the classes directly - the bundle doesn't even have to exist at
that point. Once the bundle is constructed additional functional
testing can be performed, but that should just be against the public
interfaces.
Ralph
