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 project. 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. Thoughts? Alex On 7/9/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Enrique Rodriguez a écrit : > On 7/9/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote: > >> Guys, >> >> 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 > module. > > 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. > > Enrique > 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 ... Emmanuel
