A place for the Classpath specific tests

A place for the Classpath specific tests

[Meskauskas Audrius]

For a project as large as Classpath, it would be good to
have a tests for all important classes. Apart the standard
java.* and javax.* , this also includes the Classpath
specific classes from gnu.* namespace.  In some
packages this namespace contains many classes,
having hundreds lines of the working code. 

Even it they run ok today, staying without tests leaves a gap for
the future regression bugs. 

It is not immediatly clear if such tests can be contributed to
Mauve. With such tests the Mauve would not compile
without the newest version of Classpath. 

Classpath has its own small test suite. While not very popular
and requiring to write all tests in the form of the executable
classes, it could be treated as an alternative.

Before committing Classpath specific tests to Mauve, I would
like to discuss this question in the list.

Regards
Audrius

Re: A place for the Classpath specific tests

[Michael Koch]

On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote:
> For a project as large as Classpath, it would be good to
> have a tests for all important classes. Apart the standard
> java.* and javax.* , this also includes the Classpath
> specific classes from gnu.* namespace.  In some
> packages this namespace contains many classes,
> having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for
> the future regression bugs. It is not immediatly clear if such tests can be contributed to
> Mauve. With such tests the Mauve would not compile
> without the newest version of Classpath. Classpath has its own small test suite. While not very popular
> and requiring to write all tests in the form of the executable
> classes, it could be treated as an alternative.
> 
> Before committing Classpath specific tests to Mauve, I would
> like to discuss this question in the list.

We should really put the tests in muave. Into a specific CVS module if
needed/wanted. We have already classpath specific tests in Mauve. If we
consider an extra module is need then we should move them into it.


Michael
-- 
Java Trap: http://www.gnu.org/philosophy/java-trap.html

Re: A place for the Classpath specific tests

[Dalibor Topic]

Michael Koch wrote:
> On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote:
> 
>>For a project as large as Classpath, it would be good to
>>have a tests for all important classes. Apart the standard
>>java.* and javax.* , this also includes the Classpath
>>specific classes from gnu.* namespace.  In some
>>packages this namespace contains many classes,
>>having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for
>>the future regression bugs. It is not immediatly clear if such tests can be contributed to
>>Mauve. With such tests the Mauve would not compile
>>without the newest version of Classpath. Classpath has its own small test suite. While not very popular
>>and requiring to write all tests in the form of the executable
>>classes, it could be treated as an alternative.
>>
>>Before committing Classpath specific tests to Mauve, I would
>>like to discuss this question in the list.
> 
> 
> We should really put the tests in muave. Into a specific CVS module if
> needed/wanted. We have already classpath specific tests in Mauve. If we
> consider an extra module is need then we should move them into it.

I'd say mauve, too. If a test is Classpath specific, then it can be 
tagged as such.

cheers,
dalibor topic

Re: A place for the Classpath specific tests

[Tom Tromey]

Dalibor> I'd say mauve, too. If a test is Classpath specific, then it
Dalibor> can be tagged as such.

I agree.  We already put Classpath regression tests into Mauve.  For
things that are truly Classpath-specific, say tests for gnu.*, we can
just invent a new "classpath" tag and mention it in README.

Tom

Re: A place for the Classpath specific tests

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 2462 bytes --]

Hi,

On Sat, 2005-03-12 at 12:21 -0700, Tom Tromey wrote:
> Dalibor> I'd say mauve, too. If a test is Classpath specific, then it
> Dalibor> can be tagged as such.
> 
> I agree.  We already put Classpath regression tests into Mauve.  For
> things that are truly Classpath-specific, say tests for gnu.*, we can
> just invent a new "classpath" tag and mention it in README.

OK. How about the following patch to the README:

--- README      4 Jan 2005 20:53:30 -0000       1.20
+++ README      15 Mar 2005 17:34:46 -0000
@@ -46,6 +46,15 @@
      JDK1.1  Run JDK1.1 tests only
      JDK1.2  Run JDK1.2 tests only

+     * The GNU_CLASSPATH tag selects and runs tests specific to the
+     (internal) core classes of the Free Software Foundation GNU Classpath
+     implementation (available from http://www.gnu.org/software/classpath)
+     on which a lot of free runtimes and compilers are build (but which are
+     not guaranteed to be available on all platforms).
+     These tests can be enable by adding GNU_CLASSPATH to your KEYS variable
+     and disabled by adding !GNU_CLASSPATH to the KEYS variable.
+     All such tests are in subdirectories under gnu/testlet/classpath.
+
 If an otherwise unrecognized tag QUUX is seen, and the file
 `mauve-QUUX' exists in the mauve source directory, then the contents
 of this file are treated as a list of tags.  For instance, here is the

By having a tag and a special subdirectory for these tests it should be
simple to enable/disable these special tests for the various ways people
run mauve (by hand, make, batch_run, ant script, etc).

Then we would need to move and retag the following files:

gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/ParserEntityResolverTest.java
gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/ParserTest.java
gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/parameterDefaulter_Test.java
gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/textPreProcessor_Test.java
gnu/testlet/gnu/javax/swing/text/html/parser/support/low/Buffer/Buffer_Test.javagnu/testlet/gnu/javax/swing/text/html/parser/support/low/Constants/Constants_Test.java
gnu/testlet/gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer/ReaderTokenizer_Test.java

Did I miss any?
If people agree this is a good thing I will update the choose script and
batch_run to understand the new GNU_CLASSPATH tag.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A place for the Classpath specific tests

[Tom Tromey]

Mark> OK. How about the following patch to the README:

Looks good.

Mark> By having a tag and a special subdirectory for these tests it should be
Mark> simple to enable/disable these special tests for the various ways people
Mark> run mauve (by hand, make, batch_run, ant script, etc).

I think just putting them in a directory named after their class, like
we do for everything, will suffice.  Using 'gnu.javax.swing....'  is
just as selectable -- and obviously classpath-specific, IMO -- as
'classpath.gnu.javax.swing...'

But I don't have a strong opinion on it.

Tom