Consolidation the testing bundles

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

Hi,

currently we have two testing bundles in commons, testing and slingtest.
While the original idea of testing has been to have a general osgi/jcr
testing framework, slingtest's idea is to add sling specific test helper
stuff.

Actually looking at the two bundles, the reality looks different.
Commons testing contains dependencies to Sling already - so it is not
common. slingtest contains only a single class.

So I think we should:
- merge the two into the new slingtest module (if someone comes up with
a better name, I'm fine)
- move it out of commons as it is not common stuff
- maybe create a testing subfolder in the root where we put it?

These changes would not cause any incompatibilities as commons-testing
is released and would now be end of live with the new slingtest module
being its successor. Once we've done the move, we simply release the new
module asap. (No need to change the packages imho)

WDYT?

Regards
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

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

On Tue, Nov 17, 2009 at 4:14 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...So my suggested actions are now:
> - remove dependency to internal stuff (and adapt the tests)
> - merge both testing modules into a single one
> - move the testing module out of commons...

+0, makes sense but I cannot help ATM.
-Bertrand

Re: Consolidation the testing bundles

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

Alexander Klimetschek wrote:
> On Tue, Nov 17, 2009 at 20:31, Carsten Ziegeler <cz...@apache.org> wrote:
>> So you mean we should revert the whole patch and even remove the adapter
>> support?
> 
> Yes, it's probably better to drop it before it's used if maintenance
> cannot be ensured. But we should have a quick and dirty documented
> example on the Sling website on how to do (smaller) integration tests
> with sling and pax exam in addition to full Sling integration tests
> (as done by Bertrand, with http interface testing).
> 
Thanks Alex,

if removed most of the stuff and created
https://issues.apache.org/jira/browse/SLING-1195 to somehow improve the
adapter bundle.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

[Alexander Klimetschek <ak...@day.com>]

On Tue, Nov 17, 2009 at 20:31, Carsten Ziegeler <cz...@apache.org> wrote:
> So you mean we should revert the whole patch and even remove the adapter
> support?

Yes, it's probably better to drop it before it's used if maintenance
cannot be ensured. But we should have a quick and dirty documented
example on the Sling website on how to do (smaller) integration tests
with sling and pax exam in addition to full Sling integration tests
(as done by Bertrand, with http interface testing).

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Consolidation the testing bundles

[Karl Pauls <ka...@gmail.com>]

On Tue, Nov 17, 2009 at 8:57 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Tue, Nov 17, 2009 at 8:31 PM, Carsten Ziegeler <cz...@apache.org> wrote:
>> Alexander Klimetschek wrote:
>>>> I would say go with simple unit tests where you can work with mock
>>>> objects. If you need a full blown resource resolver, just use pax exam,
>>>> fire up an osgi framework and start the jcr bundle. It's really easy to
>>>> do this.
>>>
>>> How fast is it? Can you provide an example?
>> It's not fast, but it's fast enough for a unit test.
>> Apache Felix junit4osgi is an alternative that we could use as well,
>> it's a little bit faster.
>> I don't have an example :) I tried to write some tests some weeks ago
>> and got there very quickly. I think Felix is using this for testing
>> config admin and scr....
>
> The jcrinstall osgi controller tests use pax exam, see
> http://svn.apache.org/repos/asf/sling/trunk/installer/osgi/it
>
> Currently pax exam starts the framework for each test, for isolation.
> That can be a bit slow, but it's not too bad as it's easy to select
> single tests for execution when needed.

Don't underestimate that, the felix trunk now takes ages to build if
you forget to disable tests. It sure would be nice if pax exam would
be able to test inside the same vm and run more then one testclass in
the same felix instance :-(

regards,

Karl

> The Maven CLI plugin [1] also
> helps run single tests much faster.
>
> -Bertrand
>
> [1] http://grep.codeconsult.ch/2009/05/05/faster-testing-with-the-maven-cli-plugin/
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: Consolidation the testing bundles

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

On Tue, Nov 17, 2009 at 8:31 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Alexander Klimetschek wrote:
>>> I would say go with simple unit tests where you can work with mock
>>> objects. If you need a full blown resource resolver, just use pax exam,
>>> fire up an osgi framework and start the jcr bundle. It's really easy to
>>> do this.
>>
>> How fast is it? Can you provide an example?
> It's not fast, but it's fast enough for a unit test.
> Apache Felix junit4osgi is an alternative that we could use as well,
> it's a little bit faster.
> I don't have an example :) I tried to write some tests some weeks ago
> and got there very quickly. I think Felix is using this for testing
> config admin and scr....

The jcrinstall osgi controller tests use pax exam, see
http://svn.apache.org/repos/asf/sling/trunk/installer/osgi/it

Currently pax exam starts the framework for each test, for isolation.
That can be a bit slow, but it's not too bad as it's easy to select
single tests for execution when needed. The Maven CLI plugin [1] also
helps run single tests much faster.

-Bertrand

[1] http://grep.codeconsult.ch/2009/05/05/faster-testing-with-the-maven-cli-plugin/

Re: Consolidation the testing bundles

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

Alexander Klimetschek wrote:
> Ok, I have seen the change. That's ok for sling i18n.
> 
> I wrote the slingtesthelper before the i18n tests, with the
> requirement of a full resolver at hand.
> 
Yes, and I really appreciate your effort.

>> I would say go with simple unit tests where you can work with mock
>> objects. If you need a full blown resource resolver, just use pax exam,
>> fire up an osgi framework and start the jcr bundle. It's really easy to
>> do this.
> 
> How fast is it? Can you provide an example?
It's not fast, but it's fast enough for a unit test.
Apache Felix junit4osgi is an alternative that we could use as well,
it's a little bit faster.
I don't have an example :) I tried to write some tests some weeks ago
and got there very quickly. I think Felix is using this for testing
config admin and scr.

> 
> The nice thing about my approach is that I can selectively create the
> objects I need. A pax based solution should allow the same. Having to
> activate every component, even those that aren't tested at all, can
> slow down things.
Yes, but honestly, is this important for a test? Does it matter if the
test takes 2 seconds or 15 seconds? Ok there is a break even point of
course.

> However, as the i18n module no longer requires slingtest, and nobody
> likes this, I think a veto on SLING-1166 is required and you can drop
> it. 
Oh no, it's not that nobody likes it, I like the idea - but not how it
is done.
So you mean we should revert the whole patch and even remove the adapter
support?

> My aim with this was to make it easier to write unit tests this
> way. My fear is that requiring an additional framework (pax) for unit
> tests (dependencies ++) increases the burden for writing unit tests at
> all.
Yes, it would be great if writing junit tests becomes easier. And again
I appreciate your effort. However, I doubt that even if we have this, we
get more junit tests. Its more like this old meme where people think
that it requires a great documentation app in order to motivate people
to write docs. As always there is some truth in it, but even with
something like this in place, the situation does not alter from one day
to another.

Regards
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

[Alexander Klimetschek <ak...@day.com>]

On Tue, Nov 17, 2009 at 16:56, Carsten Ziegeler <cz...@apache.org> wrote:
> Alexander Klimetschek wrote:
>
>> The jcr resource resolver used must be a real one and not a mock
>> object! The thing about the SlingTestHelper is that it makes your life
>> easier by working in a way not requiring an osgi framework running in
>> the unit test. That requires some tricks (incl. access to internal
>> packages), because configuration for most objects can normally only be
>> provided via osgi config. Same for the AdapterManagerTestHelper (still
>> in commons/testing, but part of the SlingTestHelper code from the
>> SLING-1166 patch).
> I already changed the test in the i18n bundle to use a mocked object.
> And it works as only two methods of the resolver are used.

Ok, I have seen the change. That's ok for sling i18n.

I wrote the slingtesthelper before the i18n tests, with the
requirement of a full resolver at hand.

> Using internal classes of other bundles will create a problem over time.

Agreed, but it was the simplest solution.

> All bundles in commons are well common stuff which is not tied to sling
> at all. As we have sling specific stuff in it, it doesn't fit in the
> commons category.

Agreed. I just added the code to the one existing test helper bundle initially.

> So the purpose of this bundle is indeed to make writing sling tests
> easier. But I think we should not create more and more classes for
> problems that could be solved in another way much easier.
> For example, the patch added some mock classes to the adapter package
> whereas the bundle already had mock classes for this stuff.
> The TestHelper uses an internal package name which seems odd as well.

The reason were package protected methods.

> And I really would apply YAGNI - the new stuff added is only partially
> used in Sling itself.
>
> I would say go with simple unit tests where you can work with mock
> objects. If you need a full blown resource resolver, just use pax exam,
> fire up an osgi framework and start the jcr bundle. It's really easy to
> do this.

How fast is it? Can you provide an example?

The nice thing about my approach is that I can selectively create the
objects I need. A pax based solution should allow the same. Having to
activate every component, even those that aren't tested at all, can
slow down things.

However, as the i18n module no longer requires slingtest, and nobody
likes this, I think a veto on SLING-1166 is required and you can drop
it. My aim with this was to make it easier to write unit tests this
way. My fear is that requiring an additional framework (pax) for unit
tests (dependencies ++) increases the burden for writing unit tests at
all.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Consolidation the testing bundles

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

Alexander Klimetschek wrote:

> The jcr resource resolver used must be a real one and not a mock
> object! The thing about the SlingTestHelper is that it makes your life
> easier by working in a way not requiring an osgi framework running in
> the unit test. That requires some tricks (incl. access to internal
> packages), because configuration for most objects can normally only be
> provided via osgi config. Same for the AdapterManagerTestHelper (still
> in commons/testing, but part of the SlingTestHelper code from the
> SLING-1166 patch).
I already changed the test in the i18n bundle to use a mocked object.
And it works as only two methods of the resolver are used.

> 
> A better solution (w/o requiring unit tests to run a osgi framework)
> could be that those bundles make such a usage simpler, w/o having to
> depend on internal classes. But using internal packages for unit
> testing is IMO ok (and merely a blocker, because IDE test runners such
> as in Eclipse or the maven surefire plugin use the full jars for the
> classpath anyway and do not use the osgi bundle header).
Using internal classes of other bundles will create a problem over time.

> Also, these tests are intended to be used by non-Sling code. I moved
> them over from our product (cq5) where they are used for quite a few
> unit tests. The unit tests still use the original code in the product,
> but I wanted to switch over to the Sling variant and drop that old
> code.
> 
> I would keep them split. The question is what commons.testing is
> about? Is it mainly for making it easier to write tests for sling core
> bundles? In that case we definitely have a circular dependency and
> must keep both split. Otherwise we can merge them and move them out.
> The SlingTestHelper itself should never grow to have more dependencies
> than just that of the (few) core bundles.
> 
All bundles in commons are well common stuff which is not tied to sling
at all. As we have sling specific stuff in it, it doesn't fit in the
commons category.

So the purpose of this bundle is indeed to make writing sling tests
easier. But I think we should not create more and more classes for
problems that could be solved in another way much easier.
For example, the patch added some mock classes to the adapter package
whereas the bundle already had mock classes for this stuff.
The TestHelper uses an internal package name which seems odd as well.
And I really would apply YAGNI - the new stuff added is only partially
used in Sling itself.

I would say go with simple unit tests where you can work with mock
objects. If you need a full blown resource resolver, just use pax exam,
fire up an osgi framework and start the jcr bundle. It's really easy to
do this.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

[Alexander Klimetschek <ak...@day.com>]

On Tue, Nov 17, 2009 at 16:14, Carsten Ziegeler <cz...@apache.org> wrote:
> But we have a problem in the slingtest module - this module uses
> internal classes of the jcr resource module - which it definitly should
> not; internal classes should imho not be used by any other library. And
> this stuff is exactly the stuff that creates the circular dependency.
> So I'm personally more in favour of removing this again!
> We have one place where it is used (in the i18n tests) and I think we
> can change the test easily by using mock objects.

The jcr resource resolver used must be a real one and not a mock
object! The thing about the SlingTestHelper is that it makes your life
easier by working in a way not requiring an osgi framework running in
the unit test. That requires some tricks (incl. access to internal
packages), because configuration for most objects can normally only be
provided via osgi config. Same for the AdapterManagerTestHelper (still
in commons/testing, but part of the SlingTestHelper code from the
SLING-1166 patch).

A better solution (w/o requiring unit tests to run a osgi framework)
could be that those bundles make such a usage simpler, w/o having to
depend on internal classes. But using internal packages for unit
testing is IMO ok (and merely a blocker, because IDE test runners such
as in Eclipse or the maven surefire plugin use the full jars for the
classpath anyway and do not use the osgi bundle header).

Also, these tests are intended to be used by non-Sling code. I moved
them over from our product (cq5) where they are used for quite a few
unit tests. The unit tests still use the original code in the product,
but I wanted to switch over to the Sling variant and drop that old
code.

> So my suggested actions are now:
> - remove dependency to internal stuff (and adapt the tests)

-1 as explained, this is not possible (AFAICS)

> - merge both testing modules into a single one
> - move the testing module out of commons

I would keep them split. The question is what commons.testing is
about? Is it mainly for making it easier to write tests for sling core
bundles? In that case we definitely have a circular dependency and
must keep both split. Otherwise we can merge them and move them out.
The SlingTestHelper itself should never grow to have more dependencies
than just that of the (few) core bundles.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: Consolidation the testing bundles

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

Ok, I did another look at the testing stuff and I think we
can for now leave most of the stuff as is, but move it out of commons -
as it has dependencies on some Sling bundles.

But we have a problem in the slingtest module - this module uses
internal classes of the jcr resource module - which it definitly should
not; internal classes should imho not be used by any other library. And
this stuff is exactly the stuff that creates the circular dependency.
So I'm personally more in favour of removing this again!
We have one place where it is used (in the i18n tests) and I think we
can change the test easily by using mock objects.

So my suggested actions are now:
- remove dependency to internal stuff (and adapt the tests)
- merge both testing modules into a single one
- move the testing module out of commons

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

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

On Mon, Nov 16, 2009 at 11:15 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote:
>> On Mon, Nov 16, 2009 at 9:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>>> ...1. o.a.s.adapter.internal
>>>
>>> Helper stuff if you're using adapter managers. If this has some common
>>> interest we could move this to the sling testing module.
>>
>> Did you check if it's currently used somewhere?
>> If not, ok to remove it.
> Strangely this is just used in the new slingtest module....so it seems
> we can remove it "somehow" (or merge it into slingtest)...

Right, so those are classes that came with the SLING-1166 patch, they
do belong in the slingtest module.

>>>... 4. o.a.s.c.testing.osgi
>>> Just mocks for some OSGi interfaces - I see no need for these as mock
>>> libs like jmock or easymock can be used instead.
>>
>> I assume those classes are used in existing code, did you check the
>> impact on removing them?
> Afaik, they are used - they could be easily replaced, but I think we can
> remove these without removing its usage :) The testing bundle is
> released, so if people want to use it they can use the latest release. A
> newer version won't have these anymore.
> And I would replace the usage in our sling code base over time....

Problem is, if you remove them, and we need to update the tests that
use them, and in the meantime commons/testing includes new stuff that
those tests need, we have to rewrite those tests completely... (clear
enough? ;-)

I'd much prefer modifying the tests first, so that those mock classes
are not needed anymore, and only then remove those mocks. Or, for now,
just mark those mocks deprecated to remind us that we want to do that
change.

I'm quite busy with other stuff this week and the next, won't have
much time to help on that unfortunately.

-Bertrand

Re: Consolidation the testing bundles

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

Bertrand Delacretaz wrote:
> Hi,
> 
> On Mon, Nov 16, 2009 at 9:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
>> I've looked at our commons testing again, and personally I'm not sure if
>> we need most of the stuff anyway :)
>>
>> Let's have a look at the packages:
>> 1. o.a.s.adapter.internal
>>
>> Helper stuff if you're using adapter managers. If this has some common
>> interest we could move this to the sling testing module.
> 
> Did you check if it's currently used somewhere?
> If not, ok to remove it.
Strangely this is just used in the new slingtest module....so it seems
we can remove it "somehow" (or merge it into slingtest)

> 
>> 2. o.a.s.c.testing.integration
>> Some http stuff which is only of interest for integration testing.
>> Doesn't really hurt, but there is rarely interest in plain junit tests.
> 
> I created the commons/testing module to support our integration test
> modules and hopefully help people do integration testing, so those
> classes do belong somewhere.
Yes, sure - and that's a good thing!

> If you want to move them to a separate integration-testing module I'm
> fine with that, but personally I don't care much about the distinction
> between "pure" JUnit testing and integration testing.
Yepp, I was thinking along the same lines, maybe it's not worth
separating it know, but it might over time if this stuff gets bigger.

> 
>> ...3. o.a.s.c.testing.jcr
>> Some Mock classes for JCR and the RepositoryUtil - I think this class is
>> great for doing JCR based tests - however I think this is something
>> Jackrabbit should provide us!..
> 
> If you want to donate/move that to Jackrabbit I'm fine.
I'll try

> 
>> In addition we currently have a dependency to Sling API here, so we have
>> to split it anyway.
> 
> right
> 
>> 4. o.a.s.c.testing.osgi
>> Just mocks for some OSGi interfaces - I see no need for these as mock
>> libs like jmock or easymock can be used instead.
> 
> I assume those classes are used in existing code, did you check the
> impact on removing them?
Afaik, they are used - they could be easily replaced, but I think we can
remove these without removing its usage :) The testing bundle is
released, so if people want to use it they can use the latest release. A
newer version won't have these anymore.
And I would replace the usage in our sling code base over time.

>> 5. o.a.s.c.testing.sling
>> Mocks for some sling apis - again, I see no need for explicit mock classes.
> 
> Same as above
Yepp.

> 
>> 6. o.a.s.c.testing.util
>> A single class with a single String method that replaces "\n" with a
>> dot. Don't think that this is of general use - it is only used in the
>> jst bundle atm, so we should rather move it there.
> 
> Right, if it's only used there that makes sense.
> 
>> As a conclusion I think we don't need a commons testing module, given
>> the fact that jackrabbit would provide us a repository util class that
>> can easily be used for testing - I think this makes sense to be provided
>> by Jackrabbit for all possible clients of Jackrabbit not just sling.
> 
> I want the integration testing helpers to stay, but as indicated I'm
> not against changing the name of the module that supplies them.
Yes, makes sense.

Thanks
Carsten
> 
>> The relevant stuff dealing with Sling specific test helpers can then be
>> moved into the new module.
> 
> Agreed.
> 
> -Bertrand
> 


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

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

Hi,

On Mon, Nov 16, 2009 at 9:59 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> I've looked at our commons testing again, and personally I'm not sure if
> we need most of the stuff anyway :)
>
> Let's have a look at the packages:
> 1. o.a.s.adapter.internal
>
> Helper stuff if you're using adapter managers. If this has some common
> interest we could move this to the sling testing module.

Did you check if it's currently used somewhere?
If not, ok to remove it.

> 2. o.a.s.c.testing.integration
> Some http stuff which is only of interest for integration testing.
> Doesn't really hurt, but there is rarely interest in plain junit tests.

I created the commons/testing module to support our integration test
modules and hopefully help people do integration testing, so those
classes do belong somewhere.

If you want to move them to a separate integration-testing module I'm
fine with that, but personally I don't care much about the distinction
between "pure" JUnit testing and integration testing.

> ...3. o.a.s.c.testing.jcr
> Some Mock classes for JCR and the RepositoryUtil - I think this class is
> great for doing JCR based tests - however I think this is something
> Jackrabbit should provide us!..

If you want to donate/move that to Jackrabbit I'm fine.

> In addition we currently have a dependency to Sling API here, so we have
> to split it anyway.

right

> 4. o.a.s.c.testing.osgi
> Just mocks for some OSGi interfaces - I see no need for these as mock
> libs like jmock or easymock can be used instead.

I assume those classes are used in existing code, did you check the
impact on removing them?

> 5. o.a.s.c.testing.sling
> Mocks for some sling apis - again, I see no need for explicit mock classes.

Same as above

> 6. o.a.s.c.testing.util
> A single class with a single String method that replaces "\n" with a
> dot. Don't think that this is of general use - it is only used in the
> jst bundle atm, so we should rather move it there.

Right, if it's only used there that makes sense.

> As a conclusion I think we don't need a commons testing module, given
> the fact that jackrabbit would provide us a repository util class that
> can easily be used for testing - I think this makes sense to be provided
> by Jackrabbit for all possible clients of Jackrabbit not just sling.

I want the integration testing helpers to stay, but as indicated I'm
not against changing the name of the module that supplies them.

> The relevant stuff dealing with Sling specific test helpers can then be
> moved into the new module.

Agreed.

-Bertrand

Re: Consolidation the testing bundles

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

I've looked at our commons testing again, and personally I'm not sure if
we need most of the stuff anyway :)

Let's have a look at the packages:
1. o.a.s.adapter.internal

Helper stuff if you're using adapter managers. If this has some common
interest we could move this to the sling testing module.

2. o.a.s.c.testing.integration
Some http stuff which is only of interest for integration testing.
Doesn't really hurt, but there is rarely interest in plain junit tests.

3. o.a.s.c.testing.jcr
Some Mock classes for JCR and the RepositoryUtil - I think this class is
great for doing JCR based tests - however I think this is something
Jackrabbit should provide us!
In addition we currently have a dependency to Sling API here, so we have
to split it anyway.

4. o.a.s.c.testing.osgi
Just mocks for some OSGi interfaces - I see no need for these as mock
libs like jmock or easymock can be used instead.

5. o.a.s.c.testing.sling
Mocks for some sling apis - again, I see no need for explicit mock classes.

6. o.a.s.c.testing.util
A single class with a single String method that replaces "\n" with a
dot. Don't think that this is of general use - it is only used in the
jst bundle atm, so we should rather move it there.

As a conclusion I think we don't need a commons testing module, given
the fact that jackrabbit would provide us a repository util class that
can easily be used for testing - I think this makes sense to be provided
by Jackrabbit for all possible clients of Jackrabbit not just sling.

The relevant stuff dealing with Sling specific test helpers can then be
moved into the new module.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

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

Hi,

On Fri, Nov 13, 2009 at 7:10 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...So maybe we should just move both bundles to a new location...

Not sure why you'd want to do that, commons/testing should be rather generic?

Or maybe it's not as generic as it used to be before
http://svn.apache.org/viewvc?view=revision&revision=832916 - that's
when I committed the SLING-1166 stuff, and later noticed that this
introduced a circular dependency, and moved SlingTestHelper to the new
slingtest module.

> ...and move the
> sling stuff from commons-testing to commons-slingtest - that should give
> us clean dependencies....

Yes, that should be good. But make sure you do a complete build
including integration tests if you do that ;-)

-Bertrand

Re: Consolidation the testing bundles

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

Alexander Klimetschek wrote:
> On Fri, Nov 13, 2009 at 18:30, Carsten Ziegeler <cz...@apache.org> wrote:
>> currently we have two testing bundles in commons, testing and slingtest.
>> While the original idea of testing has been to have a general osgi/jcr
>> testing framework, slingtest's idea is to add sling specific test helper
>> stuff.
>>
>> Actually looking at the two bundles, the reality looks different.
>> Commons testing contains dependencies to Sling already - so it is not
>> common. slingtest contains only a single class.
>>
>> So I think we should:
>> - merge the two into the new slingtest module (if someone comes up with
>> a better name, I'm fine)
>> - move it out of commons as it is not common stuff
>> - maybe create a testing subfolder in the root where we put it?
>>
>> These changes would not cause any incompatibilities as commons-testing
>> is released and would now be end of live with the new slingtest module
>> being its successor. Once we've done the move, we simply release the new
>> module asap. (No need to change the packages imho)
> 
> The SlingTestHelper class in commons/slingtest was meant to be for
> commons/testing originally. I think Bertrand had to split the two
> because of circular dependencies, although I don't know which exactly.
> Probably api, jcr.api or jcr.resource, which are used by slingtest,
> use commons/testing themselves.
> 
Ah right, that's another problem. So again things get more complicated...


> If moving out of commons would solve this somehow, +1 for merging them back.
Not really unfortunately. But nonetheless we already have some problems
here, as the commons-testing already contains references to sling stuff
which is wrong.

So maybe we should just move both bundles to a new location and move the
sling stuff from commons-testing to commons-slingtest - that should give
us clean dependencies.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Consolidation the testing bundles

[Alexander Klimetschek <ak...@day.com>]

On Fri, Nov 13, 2009 at 18:30, Carsten Ziegeler <cz...@apache.org> wrote:
> currently we have two testing bundles in commons, testing and slingtest.
> While the original idea of testing has been to have a general osgi/jcr
> testing framework, slingtest's idea is to add sling specific test helper
> stuff.
>
> Actually looking at the two bundles, the reality looks different.
> Commons testing contains dependencies to Sling already - so it is not
> common. slingtest contains only a single class.
>
> So I think we should:
> - merge the two into the new slingtest module (if someone comes up with
> a better name, I'm fine)
> - move it out of commons as it is not common stuff
> - maybe create a testing subfolder in the root where we put it?
>
> These changes would not cause any incompatibilities as commons-testing
> is released and would now be end of live with the new slingtest module
> being its successor. Once we've done the move, we simply release the new
> module asap. (No need to change the packages imho)

The SlingTestHelper class in commons/slingtest was meant to be for
commons/testing originally. I think Bertrand had to split the two
because of circular dependencies, although I don't know which exactly.
Probably api, jcr.api or jcr.resource, which are used by slingtest,
use commons/testing themselves.

If moving out of commons would solve this somehow, +1 for merging them back.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com