You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Morgan Delagrange <md...@yahoo.com> on 2002/02/26 18:00:29 UTC
[Commons] Testing "sub-components"
Hi all,
In filling out some of the unit tests for Collections, I've noticed that
there are quite a few tests and methods that are useful in a more general
sense. For example:
TestObject methods for testing equals() and hashCode()
TestObject methods for performing Serialization in-memory and to disk
TestMap, TestCollection
I was wondering if it makes sense to create releasable "sub-components"
(with separate dependencies) of lang, io, collections, servlet, etc. that
contain the basis of common unit tests. This would allow users to benefit
from tests that we write, and allow us to formalize the types of test that
we run on our components.
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, ?
- Morgan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: "Morgan Delagrange" <mo...@apache.org>
Sent: Tuesday, February 26, 2002 11:36 AM
Subject: Re: [Commons] Testing "sub-components"
> "Morgan Delagrange" <md...@yahoo.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by "Michael A. Smith" <mi...@iammichael.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>;
"Morgan Delagrange" <mo...@apache.org>
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Henri Yandell <ba...@generationjava.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Morgan Delagrange <md...@yahoo.com>.
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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" <md...@yahoo.com> 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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Henri Yandell <ba...@generationjava.com>.
Leading to:
Test: TestObject, TestSerialization, ... ???
On Tue, 26 Feb 2002, Daniel Rall wrote:
> "Morgan Delagrange" <md...@yahoo.com> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Commons] Testing "sub-components"
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Morgan Delagrange" <md...@yahoo.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>