separating webapp and integration tests

[Felix Meschberger <fm...@gmail.com>]

Hi all,

I am working on SLING-190 [1] which is concerned with providing a quick
hint on Sling startup if started on a pre-1.5 VM. To implement this, the
Sling launcher and servlet must be compiled with source/target settings
for the compiler for the classes to be usable on pre-1.5 VMs.

This is basically no problem as the classes may just be converted back
to non-generic Java and with the correct compiler setup for the project.

The problem is with the integration tests. I don't think it is worth the
effort porting theses tests back to be pre-1.5 compatible. But as I
cannot find a way of configuring the compiler plugin differently for the
compile and the test-compile phases, I only see a solution by splitting
the web app (to be compiled for pre-1.5) and the integration tests (to
be compiled for 1.5).

OTOH it is also up to discussion, whether we implement SLING-190 at
all ?

WDYT ?

Regards
Felix

[1] https://issues.apache.org/jira/browse/SLING-190

Re: separating webapp and integration tests

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
> Hi,
> 
> Am Donnerstag, den 13.03.2008, 11:43 +0100 schrieb Bertrand Delacretaz:
>> On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>
>>> ...I only see a solution by splitting
>>>  the web app (to be compiled for pre-1.5) and the integration tests (to
>>>  be compiled for 1.5)....
>> I'd be ok with that, provided that doesn't make running or developing
>> the tests harder.
>>
>> A related thing that has been on my mind for a while is to allow OSGi
>> bundles to contain automated tests that could be executed via the
>> Sling console or via a Sling test harness. That's probably not too
>> hard to do, and that would allow the integration tests to be simply
>> provided as a bundle, but I don't have cycles ATM to work on that.
> 
> That would be an interesting approache to splitting the integration
> tests and the web app: the tests are deployed as just another bundle and
> then there would be some runtime controller to start them ...
Not sure, if this helps, but the Spring Dynamic Modules stuff provides 
an extension to a junit test which automatically starts the osgi 
container (Felix, Equinox etc.), deploys the bundle, runs the tests and 
then shuts down everything. You can list additional bundles to be 
deployed. This looked very easy and nice to me, but I didn't had time to 
test drive it yet.

Carsten

> 
>>> ... OTOH it is also up to discussion, whether we implement SLING-190 at
>>>  all ?...
>> I think it's good to have such startup environment checks, if that's
>> not too "expensive".
> 
> The most expensive part was reverting the generics stuff we used in the
> app and webapp to plain old Java. That's it. The rest is not concerned,
> and this is actually quite nice ;-)
> 
> Regards
> Felix
> 
>> -Bertrand
> 
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: separating webapp and integration tests

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Donnerstag, den 13.03.2008, 11:43 +0100 schrieb Bertrand Delacretaz:
> On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <fm...@gmail.com> wrote:
> 
> > ...I only see a solution by splitting
> >  the web app (to be compiled for pre-1.5) and the integration tests (to
> >  be compiled for 1.5)....
> 
> I'd be ok with that, provided that doesn't make running or developing
> the tests harder.
> 
> A related thing that has been on my mind for a while is to allow OSGi
> bundles to contain automated tests that could be executed via the
> Sling console or via a Sling test harness. That's probably not too
> hard to do, and that would allow the integration tests to be simply
> provided as a bundle, but I don't have cycles ATM to work on that.

That would be an interesting approache to splitting the integration
tests and the web app: the tests are deployed as just another bundle and
then there would be some runtime controller to start them ...

> 
> > ... OTOH it is also up to discussion, whether we implement SLING-190 at
> >  all ?...
> 
> I think it's good to have such startup environment checks, if that's
> not too "expensive".

The most expensive part was reverting the generics stuff we used in the
app and webapp to plain old Java. That's it. The rest is not concerned,
and this is actually quite nice ;-)

Regards
Felix

> 
> -Bertrand

Re: separating webapp and integration tests

[Bertrand Delacretaz <bd...@apache.org>]

On Wed, Mar 12, 2008 at 10:55 PM, Felix Meschberger <fm...@gmail.com> wrote:

> ...I only see a solution by splitting
>  the web app (to be compiled for pre-1.5) and the integration tests (to
>  be compiled for 1.5)....

I'd be ok with that, provided that doesn't make running or developing
the tests harder.

A related thing that has been on my mind for a while is to allow OSGi
bundles to contain automated tests that could be executed via the
Sling console or via a Sling test harness. That's probably not too
hard to do, and that would allow the integration tests to be simply
provided as a bundle, but I don't have cycles ATM to work on that.

> ... OTOH it is also up to discussion, whether we implement SLING-190 at
>  all ?...

I think it's good to have such startup environment checks, if that's
not too "expensive".

-Bertrand