On 9 Dec 2003, at 15:14, Eric Johnson wrote:
As someone who has only provided patches to Slide, and then only on the webdav client stuff, I'll toss in a perspective...:
The "test" code ought to live in the same module as the server side code, if only because the two will be inseperable.
? I think this is a pretty bad thing to do. Writing a test scenario that runs against different servers makes it more compliant. I don't want to have anything slide specific in the general DeltaV tests.
I agree with you that slide specific tests should go into the slide module, but general WebDAV ones would be better off (IMHO, of course) in a different module.
Over time, in conjunction with coverage analysis, the test hierarchy will include performance loading tests, threading tests, authentication tests, and places where the specification is in fact ambiguous as to what should be done.
As I said, I'm ok for slide-specific tests to be inside slide, but i don't see why general tests should have to be tied to slide in any way.
With all these specific parts, at best I can see that the test framework can have a portion that is intended to be "standard", and that which is specific to the Slide implementation. Maybe I'm wrong, but I don't see the sense in separation.
There is no right or wrong, here. It's just a matter of setting free the tests to be used against other implementations: having them in the slide repository makes it hard to do.
Note: my proposal for the separation goes along with the path of proposing the creation of a dav.apache.org top-level-domain for the ASF. In that regard, it makes perfect sense to separate the things because they are, in fact, different subprojects of slide.
As for the client side stuff, it would be very disappointing if the projects were decoupled to the extent that a client might possibly not interoperate with the server on occassion.
First of all, this is already the case today (the client API fails with a NPE on some DASL calls), so I don't see the existance in the same module helping there.
Second, the tests are using the slide client API to connect to the server. As long as we keep doing that, the tests will either indicate problems within the client API or the server API, but the incompatibility will show up.
This is less important, though, as presumably the test hierarchy will dramatically reduce the chances of an interoperability failure.
yep
Having worked on Slide client side code, though, I can say that it being a part of a much bigger project was not a big barrier to working with the code. However, having a server against which the code can be tested is/would be helpful (although since Slide didn't have an out-of-the-box solution, I never did figure out how to set it up to test against it).
I think separation helps in this regard: you have a build file for the tests, a build file for the server and one for the client.
I guess the real question is whether those of you who are CVS committers really want to narrow your focus, and perhaps restrict your permissions.
I don't want to narrow focus, I want to increase focus.
At the same time, my proposal doesn't seem to get lots of traction so I might just propose to move things around so that we have
/client /server /tests
all inside the jakarta-slide CVS module.
Is that any better?
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
