directory-dev mailing list archives

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

Thank you, I believe I knew that already, but was drawing a blank this

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 <>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