Re: Eclipse and Classpath

Re: Eclipse and Classpath

[Archie Cobbs]

David P Grove wrote:
> > IIRC the biggest problem with using JUnit is that it depends of rather 
> > advanced JVM features; like reflection.
> 
> Sorry if this is an ignorant question, but is this really an issue?  I'd 
> always assumed (without actually checking) that most (all?) of the VMs 
> being used by classpath developers implement reflection.  If this is the 
> case, then maybe making reflection a pre-req for being able to run mauve 
> wouldn't be an issue.  It's hard to run very much Java code these days 
> without running into some use of reflection by the application.

I inferred the problem to be that reflection is one of the things
we want to test, so we shouldn't be relying on it for the test itself.
Of course, if reflection doesn't work, then the test will probably
still fail :-) But it may make it harder to track down the real problem.

All in all, it's probably not a major deal... Perhaps there could be
a small set of basic reflection tests that didn't use JUnit too.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com

Re: Eclipse and Classpath

[C. Brian Jones]

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

On Wed, 2004-04-28 at 18:50, Archie Cobbs wrote:
> David P Grove wrote:
> > > IIRC the biggest problem with using JUnit is that it depends of rather 
> > > advanced JVM features; like reflection.
> > 
> > Sorry if this is an ignorant question, but is this really an issue?  I'd 
> > always assumed (without actually checking) that most (all?) of the VMs 
> > being used by classpath developers implement reflection.  If this is the 
> > case, then maybe making reflection a pre-req for being able to run mauve 
> > wouldn't be an issue.  It's hard to run very much Java code these days 
> > without running into some use of reflection by the application.
> 
> I inferred the problem to be that reflection is one of the things
> we want to test, so we shouldn't be relying on it for the test itself.
> Of course, if reflection doesn't work, then the test will probably
> still fail :-) But it may make it harder to track down the real problem.
> 
> All in all, it's probably not a major deal... Perhaps there could be
> a small set of basic reflection tests that didn't use JUnit too.

Junit does not require reflection if used in a particular manner.  See
http://junit.sourceforge.net/doc/testinfected/testing.htm.  But it's
probably easier all around if reflection is allowed.

JUnit supports two ways of running single tests: 
      * static
      * dynamic
In the static way you override the runTest method inherited from
TestCase and call the desired test case. A convenient way to do this is
with an anonymous inner class. Note that each test must be given a name,
so you can identify it if it fails. 
TestCase test= new MoneyTest("simple add") {
    public void runTest() {
        testSimpleAdd();
    }
};

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

Re: Eclipse and Classpath

[Tom Tromey]

>>>>> "Thomas" == Thomas Zander <zander@javalobby.org> writes:

Thomas> IIRC the biggest problem with using JUnit is that it depends
Thomas> of rather advanced JVM features; like reflection.

Yeah.  However, Mauve already uses Class.forName and
Class.newInstance, so it is already relying on some reflection
capability.

Also, when Mauve was started, gcj limitations drove some of the design
decisions.  In particular we set things up carefully to avoid
functionality we knew would not work with gcj.  Since then things have
changed; all the free VMs are much more capable.

Tom

Re: Eclipse and Classpath

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 28 April 2004 21:51, Tom Tromey wrote:
> Jeff> (What about Mauve?  Much of Eclipse's usefulness for us comes from
> Jeff> interactively running the test suite so we get a very quick
> Jeff> edit/compile/test/debug cycle.  But eclipse only knows about
> junit-style Jeff> tests, not the gnu.testlet classes in Mauve.)
>
> I think Graydon changed Mauve to use JUnit at one point, but it never
> went in.  I think there was some confusion about some points I made.
>
> It's time to revisit this (various folks pointed this out to me at the
> recent RH meeting).  IMO anything that makes Mauve easier to hack is a
> good thing.  My only real requirement is that we still be able to run
> the gcj test suite; I don't think there is any substantial problem
> here.

IIRC the biggest problem with using JUnit is that it depends of rather 
advanced JVM features; like reflection.

Its technically possible to have a mauve test case extend a 
mauve-base-class which can be changed on run-time (probably using a 
singleton) to either use the very-simple-mauve test framework, or the 
JUnit ones. Using a facade pattern in that baseclass.
Its still needed to call each test in one long test() method if you want to 
use the mauve version, but other then that it would integrate with JUnit 
quite nicely.

Naturally all tests will need to be refactored to do this..
- - extending a base class instead of implementing Testlet
- - using the assertTrue() style checking instead of the check() versions.

Thoughts?

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAkCgpCojCW6H2z/QRAp0LAKCxgcsGMzDHdMPDDVDTPUBNPCQjGgCgkU8j
qAf1uGZxFCYoTpSJreFpitY=
=nRwQ
-----END PGP SIGNATURE-----

Re: Eclipse and Classpath

[Tom Tromey]

Jeff> (What about Mauve?  Much of Eclipse's usefulness for us comes from
Jeff> interactively running the test suite so we get a very quick
Jeff> edit/compile/test/debug cycle.  But eclipse only knows about junit-style
Jeff> tests, not the gnu.testlet classes in Mauve.)

I think Graydon changed Mauve to use JUnit at one point, but it never
went in.  I think there was some confusion about some points I made.

It's time to revisit this (various folks pointed this out to me at the
recent RH meeting).  IMO anything that makes Mauve easier to hack is a
good thing.  My only real requirement is that we still be able to run
the gcj test suite; I don't think there is any substantial problem
here.

Tom