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 :)
The first module (core-unit) contains junit extensions for integration tests as sources
and in the test area contains integration tests which use these junit extensions. These
junit extensions start up the core of ADS without any MINA based network services.
The second, server-unit, contains integration tests which test the network services of
ADS. Up until this point we have just had LDAP network tests. However we can add
any kind of network protocol test to these tests.
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
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.
For now I say because I'd like to keep the tests together as much as possible since we
may soon need to refactor these integration tests to use one or more test suites that starts
a single server which is cleaned out rather than deleted and restarted for each test method
or test class. Clumping the integration tests into packages may make this job easier down
the road for us.
Enrique Rodriguez a écrit :
> On 7/9/07, Emmanuel Lecharny < email@example.com> wrote:
>> I did a simple test on my laptop writing a kerberos-unity project,
>> mimicing the server-unit project. I think that this should be a good
>> approach, as you don't have anymore dependency to deal with.
>> wdyt ?
> What would you do in the case of SASL GSSAPI bind tests, which use
> both Kerberos and LDAP? I am in favor of a single integration test
> Similarly, integration tests for Change Password would use Change
> Password and Kerberos.
> kerberos-unit would make sense if you were only testing the Kerberos
> protocol, but then why not just put the tests in protocol-kerberos.
In my mind, you should always write separate tests for separate
elements. If you want to test SASL GSSAPI, nothing forbid you to create
a GSSAPI-unit project, where you launch a kerberos + ldap server. The
very same for changepw.
At least, it will help people like me who are trying to cope with
Kerberos and all the other related subprojects : it will provide a clear
base for each project's tests, instead of mixing everything in a giant
server-uni catch all test.
As we already have around 50 subprojects, 3 more won't harm a lot ...