Integration testing based on feature model

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Integration testing based on feature model

Jörg Hoh-2
Hi,

I recently came across the IT tests of the Sling Event bundle [1], and my
personal opinion is that having such a listing of bundles in the
testclasses is hard to maintain.

From what I understand, the feature model is already able to collect a set
of artifacts and start a process on top of that. This could be very helpful
to define the environment in which integration testing could happen: I
define an environment as feature-model, which is augmented with the bundle
under test and the testcases, everything is started/deployed and the tests
are running afterwards.

This should allow us to use "pre-packaged" environment definitions (e.g.
"sling11-core") which we could use (and easily update) for these IT tests.

At the moment this is just an idea, and I do neither have the time nor the
knowledge to implement that. But it would make the creation of integration
tests with Sling much easier.

WDYT?

Jörg



[1]
https://github.com/apache/sling-org-apache-sling-event/blob/master/src/test/java/org/apache/sling/event/it/AbstractJobHandlingTest.java

--
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh
Reply | Threaded
Open this post in threaded view
|

Re: Integration testing based on feature model

Oliver Lietz
On Monday, July 22, 2019 10:14:45 PM CEST Jörg Hoh wrote:
> Hi,

Hi Jörg,

> I recently came across the IT tests of the Sling Event bundle [1], and my
> personal opinion is that having such a listing of bundles in the
> testclasses is hard to maintain.
>
> From what I understand, the feature model is already able to collect a set
> of artifacts and start a process on top of that. This could be very helpful
> to define the environment in which integration testing could happen: I
> define an environment as feature-model, which is augmented with the bundle
> under test and the testcases, everything is started/deployed and the tests
> are running afterwards.
>
> This should allow us to use "pre-packaged" environment definitions (e.g.
> "sling11-core") which we could use (and easily update) for these IT tests.
>
> At the moment this is just an idea, and I do neither have the time nor the
> knowledge to implement that. But it would make the creation of integration
> tests with Sling much easier.
>
> WDYT?

It's already implemented based on Sling's Karaf Features:

https://sling.apache.org/documentation/development/testing-paxexam.html

Regards,
O.

> Jörg
>
>
>
> [1]
> https://github.com/apache/sling-org-apache-sling-event/blob/master/src/test/
> java/org/apache/sling/event/it/AbstractJobHandlingTest.java




Reply | Threaded
Open this post in threaded view
|

Re: Integration testing based on feature model

Jörg Hoh-2
Hi Oli,


Am Di., 23. Juli 2019 um 16:12 Uhr schrieb Oliver Lietz <
[hidden email]>:

>
>
> It's already implemented based on Sling's Karaf Features:
>
> https://sling.apache.org/documentation/development/testing-paxexam.html
>
>
Hm, it still seems to me that the list of bundles and their versions are
all hardcoded (see SlingOptions.java). I would like to use complete
features (as provided by the feature model), because these features are
often already defined and used elsewhere (thus reuse), and secondly I can
reference them from within the POM (instead of hardcoding them in a bundle).

As much as I like your approach, I see the problem that the maven
dependencies and the IT dependencies are maintained twice and also at
different locations.

Jörg

--
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh
Reply | Threaded
Open this post in threaded view
|

Re: Integration testing based on feature model

Oliver Lietz
On Tuesday, July 23, 2019 10:08:39 PM CEST Jörg Hoh wrote:

> Hi Oli,
>
>
> Am Di., 23. Juli 2019 um 16:12 Uhr schrieb Oliver Lietz <
>
> [hidden email]>:
> > It's already implemented based on Sling's Karaf Features:
> >
> > https://sling.apache.org/documentation/development/testing-paxexam.html
>
> Hm, it still seems to me that the list of bundles and their versions are
> all hardcoded (see SlingOptions.java). I would like to use complete
> features (as provided by the feature model), because these features are
> often already defined and used elsewhere (thus reuse), and secondly I can
> reference them from within the POM (instead of hardcoding them in a bundle).
>
> As much as I like your approach, I see the problem that the maven
> dependencies and the IT dependencies are maintained twice and also at
> different locations.

The Sling "Features" (Options) provided by Testing PaxExam are really coming
from this feature file (no double maintenance):

https://github.com/apache/sling-org-apache-sling-karaf-features/blob/master/
src/main/feature/feature.xml

The two Java files are a result of applying the Handlebars templates on the
data from Sling's Karaf Features:

https://github.com/apache/sling-org-apache-sling-testing-paxexam/tree/master/
src/main/resources/templates

We have some ITs where the Provisioning Model is used, but three (probably
more) shortcomings which come to mind are:
  - dedicated module for ITs required
  - single instance for all tests (?)
  - no way to adjust Features

Solved already with Testing PaxExam, for adjusting a Feature (Option) see

https://github.com/apache/sling-org-apache-sling-jcr-contentloader/blob/
master/src/test/java/org/apache/sling/jcr/contentloader/it/
ContentloaderTestSupport.java#L89

It takes the existing Option (Features), removes the
org.apache.sling.jcr.contentloader bundle and the current bundle from build is
added as usual. The first two points are default.

There are of course more goodies included and having direct access into the
OSGi container makes several workarounds unnecessary (via HTTP: deploying
bundles, waiting for services, running tests...).

Regards,
O.

> Jörg