directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: Unit tests for ldap api classes
Date Sat, 03 May 2014 17:16:02 GMT
Hi Lucas,

I see the benefit of your approach, and maybe others already thought
about that. But maybe it is not so easy.

The client module would depend on many apacheds modules.

And currently many apacheds modules depend on the ldap-client-api module:

$ find * -name pom.xml | xargs grep -l api-ldap-client-api

I'm not sure if all of them really need the ldap-client-api module. But
to refactor is is quite some effort. I won't stop you from trying, if
you succeed I think that would be great :)

Kind Regards,

On 05/03/2014 07:05 PM, Lucas Theisen wrote:
> Hi Stefan,
> Thank you, I believe I knew that already, but was drawing a blank this
> morning.
> Should we still consider extracting out another subproject that would be a
> peer of apacheds and shared.  It would basically be the shared/ldap/client
> branch.  Then both this new client subproject and the apacheds subproject
> could depend on shared, as well as client depending on server so that it
> could contain its own unit tests.
> Its just a thought, and I am quite likely missing some reason why we don't
> do this, but it seems like it would be a good idea.
> Thanks,
> Lucas
> On Sat, May 3, 2014 at 12:57 PM, Stefan Seelmann <>wrote:
>> Hi Lucas,
>> the LDAP API integration tests are in apacheds/ldap-client-api, for the
>> exact reason you mentioned.
>> Kind Regards,
>> Stefan
>> On 05/03/2014 06:45 PM, Lucas Theisen wrote:
>>> Hi All,
>>> I am working on LdapConnectionTemplate (
>>> and am not quite sure
>>> where to put unit tests.  It appears that none of the ldap api artifacts
>>> depend on apacheds server artifacts.  I am wondering if this is a hard
>>> requirement?  And if so, how do you test the functionality of your apis?
>>> It seems that one of the major benefits of an embeddable server like
>>> apacheds is that it can be used for unit tests, but if we cannot even use
>>> it for our own unit tests...
>>> I know I could put some tests in server-integ, but that seems very wrong
>>> for testing new ldap api features.  If this is because of circular
>>> dependencies (server depends on api, so api cannot depend on server),
>> then
>>> perhaps we should refactor.  Maybe move the truly shared stuff (like
>> model
>>> and what not) into a shared library, and all the api stuff (like
>>> connections) into another.  What do you think?
>>> Thanks,
>>> Lucas

View raw message