This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Test case layout (Was: Re: FYI: Patch: java.net: socket stuff)
Hi Michael,
Michael Koch wrote:
On Tue, Nov 25, 2003 at 02:57:23PM +0100, Dalibor Topic wrote:
I've got another small wish: as you've been wrestling with the mauve
tests for DatagramSocket, and managed to understand them, maybe could
you clean them up, and separate them into one file per tested method/API.
That would make it much clearer what's being tested. I'll have my
FieldPosition mauve test refactoring & rewriting done today, maybe we
can discuss writing good mauve tests on the IRC and come up with some
small set of guidelines.
Huh ? I have no problems finding the according test when all tests are
in one file (if the tests are well written). Writing each test into one
file is really nonsense.
If all members of a class are introduced in the same API, I wouldn't
necessarily object, other than on taste issues. I usually prefer
multiple small files to a long one, but that might be just me ;)
If they are not, then you need to separate tests into multiple files, or
you can't test all aspects of a class.
Example:
class A defined in JDK 1.0
constructor A(int a) defined in JDK 1.1
method int getA() defined in JDK 1.1
method int getB() defined in JDK 1.1
method void setB(int) defined in JDK 1.2
method boolean equals(Object) defined in JDK 1.1
In order to test equals properly you must make two files at least. One
for the tests with equality with respect to modifiable fields (i.e.
states) as of JDK 1.1 (the constructor sets a), and another one with
respect to the modifiable fields in JDK 1.2 (setter method for b). You
can not test equals properly with a single file, unless you want to mash
the JDK 1.1 specific tests into the JDK 1.2 ones. Which would be bad
test design, in my opinion, as it would preclude you from running just
the JDK 1.1 tests.
cheers,
dalibor topic