On 7/9/07, Alex Karasulu <[EMAIL PROTECTED]> 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: o.a.d.server.core o.a.d.server.protocol.kerberos o.a.d.server.protocol.ldap o.a.d.server.protocol.changepw 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. Enrique
