>To be honest, I see only 2, maybe 3 cases where managing tests over HTTP >makes >sense: > >1. you do not want to start your (fat and slow) application under test from >the tests itself >2. you need a different runner than PaxExam (runners and rules are gone in >JUnit 5) >3. reuse of tests like done in o.a.s.karaf-launchpad-oak-tar-integration- >tests > >In any other case I would use Pax Exam and @Inject to ensure required >services >are available before tests are executed.
this may be true. before again using a http-based test (also with latest slingstart/provisoining features and teleporter rule they are much nicer than before) i played some minutes with paxexam and was drawn back by two isses (without further thinking or researching on them): 1. within the codebase of org.apache.sling.testing.paxexam a long list of dependencies was hard-coded. this is usually not what i want. using slingstart i reference one sling launchpad version i want to target (e.g. 8) and deploy only few additional bundles. then i can be sure that my application works exactly with this versions of dependencies and felix framework, not only with the latest and greatest versions. if paxexam could be equipped with an "externalized" dependency management based on sling provisioning files and their modularization/overlay/inheritance features this would be great. 2. paxexam integration tests do not run in the IDE (at least not in eclipse/junit runner - the problem seems to be that the pom information is not available for version lookup). this is only nice-to-have. stefan
