The reactor strategy decides if a new container should be spawned per method or per class. If I have a bunch of different tests in the same class, I would not want to spawn the container more than once, if I could avoid it, since it's expensive. The provisioned bundles etc are typically defined in the @Configuration-method, so the set of provisioned bundles is shared by all tests, regardless of reactor strategy. It sounds like you want to re-use the container for the tests in a given test class but tweak the provisioning between tests, meaning you cannot rely on the shared @Configuration-method, but have to also provision stuff in the test themselves. I have never written a Pax Exam test that works like that, not sure how robust it's going to be.
- Eric L On Fri, Mar 24, 2023 at 8:02 PM Steinar Bang <[email protected]> wrote: > >>>>> Jean-Baptiste Onofré <[email protected]>: > > > Like this one: > > > > https://github.com/apache/karaf/blob/main/itests/test/src/test/java/org/apache/karaf/itests/DiagnosticTest.java > > > For example, in this class we have several tests using a single Karaf > > instance (depending of the @ExamReactorStrategy(PerClass.class) > > annotation, PerClass meaning a single Karaf instance for all test > > methods in the class). > > Nice! Can I add a feature repo and an extra feature to load easily on a > class basis? > > I could do it with command line commands, I guess? > > I.e. add > executeCommand("feature:repo-add > mvn:no.priv.bang.modeling.modelstore/modelstore.backend/LATEST/xml/features"); > executeCommand("feature:install modelstore.backend"); > to all test methods? > > (it shouldn't matter much if I did in each test...? It should be a no-op > if the feature is already loaded...?) > >
