directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Unit tests for ldap api classes
Date Sun, 04 May 2014 21:15:13 GMT
Le 5/4/14 10:27 PM, Lucas Theisen a écrit :
> My original proposal was to
> 1: Join the client and the tests for the client.
> 2: Organize the code
> As to item 1, there is great value in that.  

But the server uses the client API, and the test uses the API too. That
makes the client test depends on the server, which depends on the API.
This is what we tried to do a long time ago, and in some corner case, it
is problematic. Typically, it may forces you to build the API without
tests, then the server, then re-run the client with tests this time.
Yes, we faced this issue, despite the fact that Maven does not care
about cyclic dependencies. This will be the case typically when we
change something in the API which impact the server (like adding an
extended operation or a control).

So, yes, we can do that, and yes, it will be painful.

> You can build the module on
> its own and have assurance that it is correct.  As it stands right now, you
> have to build/install the client, then remember to build the server to run
> the unit tests to verify that it worked.  That feels really wonky.  As to
> item 2, just guessing from the folder structure in svn, it seems like it
> was intended to be 3 parts, a server, a client, and shared code.  So I
> guess I was just wondering if we should do that.  
This is the problem. What we call the client API is also used by the
server, so it's hard to dissociate it from the shared API. Ideally, we
would like to have a shared API, a server module and a client module,
but it's not easy (again, because the server is using the client API,
and teh client API uses the server to check that it works).

ATM, the best solution for us has been to move the client tests in the
server, as everything we need is there when we run the client tests (at
the very end of the full build of the API and the server).

OTOH, creating a third project would not solve the problem of the server
needing the client-api...

This is really not simple, and we don't have a lot of good solution, if
we have any :-)

> Anyway, I'm not sure I
> understand enough to have a strong opinion on this, but that's my 2 cents.

Thanks for that ! At least, it opens a discussion that is good to have.
I don't have good solution to offer here, I was thinking that moving the
client tests in a separate project would have th ebenefit of making it
possible to run them separately, but I'm not convinced that it's relly
better, after having read Kiran's objections...

Emmanuel Lécharny 

View raw message