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.


On Sat, May 3, 2014 at 12:57 PM, Stefan Seelmann <mail@stefan-seelmann.de> wrote:
Hi Lucas,

the LDAP API integration tests are in apacheds/ldap-client-api, for the
exact reason you mentioned.

Kind Regards,

On 05/03/2014 06:45 PM, Lucas Theisen wrote:
> Hi All,
> I am working on LdapConnectionTemplate (
> https://issues.apache.org/jira/browse/DIRAPI-163) 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