directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: Kerberos implementation questions
Date Mon, 09 Jul 2007 23:58:13 GMT
On 7/9/07, Alex Karasulu <> wrote:
> Right now the organization is setup to have two kinds of integration tests
> in two separate modules:
>     core-unit => which IMO should be called core-integration :)
>     server-unit => which IMO should be called server-integration :)

I agree with these module names.

> ...
> If we add a kerberos-unit then to follow the same scheme we would have to
> rename
> server-unit to ldap-unit.  Then we would create a changepw-unit and so on.
> I don't know
> how many tests we're adding but if not that many keeping them in the same
> project
> may be less overhead both in terms of maven build time and in terms of
> managing the
> project.

I can only picture 1, maybe 2, test classes for each SASL GSSAPI,
Kerberos, and CP.  I don't see the point of separate modules with 1-2
classes.  Emmanuel makes the point that "you should always write
separate tests for separate elements" but then goes on to equate this
with separate modules (!?).  IMO, we do have separate tests already
and there is nothing confusing about having them in the same module.

> ...
> I'd recommend (for now) just putting the kerberos tests and other protocol
> tests into a
> special package to differentiate them from the LDAP integration tests in
> server-unit.  We
> eventually need to better organize them but a package level separation
> should give
> new comers enough of a cue as to the nature of the test.

I was fine with separating by test class, but package works better if
we do get above just a single test class for each protocol.  We could
even name the packages so they correspond to the module being tested,
such as:


The difference between 'core' and 'protocol.ldap' would be the intent
of the integration test, ie even though you are firing up the server
and using the LDAP protocol in both cases, the target of the test may
be the core or something in the protocol workflow.


View raw message