----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>; "Morgan Delagrange" <[EMAIL PROTECTED]> Sent: Tuesday, February 26, 2002 12:14 PM Subject: Re: [Commons] Testing "sub-components"
> > > On Tue, 26 Feb 2002, Morgan Delagrange wrote: > > > > Leading to: > > > > > > Test: TestObject, TestSerialization, ... ??? > > > > I'm not _positive_ what you mean here. I think you're implying that there > > be a "Test" component where all these tests live. I'm not sure that's a > > good idea; I think it's best if they be companion classes to each component, > > _perhaps_ packaged in the same jar as the component itself. > > Sorry, it was a bit cryptic :) It was mainly just an idea, but a > subsequent email from you about being worried about interdependency did > make me think it might not be that bad. That way thigns would only be > dependent on the Test component, which I've taken to be a component full > of generic objects used in testing. However that gets bad when those test > components start to have dependencies back on to other projects. Ya, I'm not sure that a seperate Component makes sense, even though it's tempting from an organizational standpoint. I think it would be more focused if the generic test classes were directly attached to a relevant component. > ie) TestJspSession which is dependent on having the servlet jar, and > Collections is dependent on Test, and thus on servlet jar. So I can see > that that is bad. Although, something Lance said recently leads me to > think we could set the Test component up so that it always compiles, it's > just assumed that if they want to have the Test.Servlet components > compiling then they'll need to have the Servlet package (and thus > servlet.jar) checked out and built? That's a possibility too. > > Actually, I think the names below, which I drew from the current Collections > > test classes, are slightly misleading. I think there should be a > > "TestObject" test case, which tests the methods of Object. For most other > > tasks, we probably want a library of custom asserts, rather than actual test > > cases. That seems to be the only reasonable course, since interfaces can be > > combined in any number of ways. > > Could it maybe be a common set of assertions? > > ie) TestEquality rather than TestObject. > equals/hashcode > TestReadOnlyCollection > tests iterator by running it a few times and using TestEquality? > TestRWCollection > adds and removes lots > TestMapChanging > put delete clear isEmpty etc. > TestMapEntryUsage > check the Map extension has handled entrySet properly. Right that would be a start. We probably want to use the signature assertXXX instead, because we don't want people to confuse these utility classes with actual TestCases. Inside of each custom assertXXX method, we make what evaluations we need and then call the relevant JUnit assert. So perhaps: > > Or maybe it would jsut be: > > TestCollection.testReadOnly > TestCollection.testReadWrite > TestMap.testMapEntry > > > I have a feeling I'm playing catch up and reaching your conclusion the > long way :) Definitely something more like that, I would think. I think a separate class for each test operation would become unmanageable. So perhaps: CollectionAsserts.assertReadOnlyCollection(Collection) CollectionAsserts.assertWriteableCollection(Collection) MapAsserts.assertMapEntryCompatibility(Map) It would definitely take a lot of thought to get it right, but if we nailed it, our components would be better too. - Morgan _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
