Re: [Commons] Testing sub-components
Leading to: Test: TestObject, TestSerialization, ... ??? On Tue, 26 Feb 2002, Daniel Rall wrote: Morgan Delagrange [EMAIL PROTECTED] writes: Right now, I'm not positive that there would be enough common operations to make it worthwhile, but I think it's worth considering. Perhaps: Lang: TestObject, ? IO: TestSerialization, ? Collections: TestMap, TestCollection, TestList, ? A promising idea. Any reason not to include the more generic/re-usable classes in the main JAR? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Commons] Testing sub-components
- Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 11:38 AM Subject: Re: [Commons] Testing sub-components 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. 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. - Morgan On Tue, 26 Feb 2002, Daniel Rall wrote: Morgan Delagrange [EMAIL PROTECTED] writes: Right now, I'm not positive that there would be enough common operations to make it worthwhile, but I think it's worth considering. Perhaps: Lang: TestObject, ? IO: TestSerialization, ? Collections: TestMap, TestCollection, TestList, ? A promising idea. Any reason not to include the more generic/re-usable classes in the main JAR? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ 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]
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. 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? 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. 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 :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Commons] Testing sub-components
On Tue, 26 Feb 2002, Morgan Delagrange wrote: 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. I've been thinking about the library of custom asserts a bit as well, but have yet to reach a design/impl that I'm happy with. My primary motivation was primarily for being able to use the same tests for testing the entrySet(), keySet(), and values() that are used for testing Maps, and Collections. This is almost the same thing as you imply about being able to test interfaces. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Commons] Testing sub-components
- 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]
Re: [Commons] Testing sub-components
- Original Message - From: Daniel Rall [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Cc: Morgan Delagrange [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 11:36 AM Subject: Re: [Commons] Testing sub-components Morgan Delagrange [EMAIL PROTECTED] writes: Right now, I'm not positive that there would be enough common operations to make it worthwhile, but I think it's worth considering. Perhaps: Lang: TestObject, ? IO: TestSerialization, ? Collections: TestMap, TestCollection, TestList, ? A promising idea. Any reason not to include the more generic/re-usable classes in the main JAR? Only that we might have unncessary interdependencies. For example, it's quite likely that the Collections testing classes will make use of Serialization utility methods in the IO testing classes, but that's a poor reason to make Collections itself dependent on IO. Of course, some of that you can get around with documentation (Collections is dependent on X, except for its testing classes which are dependent on X and Y. - 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]
