Am 10.02.2018 um 09:55 schrieb Stefan Bodewig: > On 2018-02-10, Simon Spero wrote: > >> Writing tests for osgi modules is painless... the second time :-P > > I said I "was pointed into a direction for writing a test ..." that's > been your and Bertrand's input. :-) > >> The key to making tests easy is to use pax-exam, which handles most of the >> tedious container setup and junit / test-NG test execution. > >> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation > > Thanks again. > >> I can implement this if OSGI related changes are wanted. > > What *I*'d want to see is a regression test that prevents us from > breaking the manifest or dropping imports that used to be there. Others > may want additional OSGI related changes. > > https://issues.apache.org/jira/browse/COMPRESS-443 >
PaxExam is really a nice tool to write integration tests running inside the OSGi container. For the purpose at hand it would be possible to create a setup that starts an embedded OSGi container and deploys the bundle created by the project. This is not fully trivial because it requires that all (transitive) dependencies are also installed in the container. Such a test checks whether the manifest is more or less syntactically correct. In order to prove that all packages are correctly exported, some more tests would have to be written that access the public API. (Ideally one would run the whole unit test suite in the container, but I doubt that this would be feasible. Some tests are probably white-box tests and access internals of a class that are not necessarily available inside OSGi.) It would be great to have some generic setup that could be reused by all Commons components. Maybe another maven plugin? It would require some functionality of the dependencies plugin to resolve all dependencies, and of the surefire plugin to run tests. Oliver > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
