From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14622 invoked by alias); 30 Jan 2005 16:11:11 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 14323 invoked from network); 30 Jan 2005 16:10:43 -0000 Received: from unknown (HELO namlook.thomas.planescape.com) (212.120.112.227) by sourceware.org with SMTP; 30 Jan 2005 16:10:43 -0000 Received: from dumas.thomas.planescape.com ([10.0.0.2] ident=zander) by namlook.thomas.planescape.com with esmtp (Exim 3.35 #1 (Debian)) id 1CvHej-0004Qp-00 for ; Sun, 30 Jan 2005 17:10:33 +0100 From: Thomas Zander To: mauve-discuss@sources.redhat.com Subject: Re: Discussing a helper class to migrate from JUnit Date: Sun, 30 Jan 2005 16:11:00 -0000 User-Agent: KMail/1.7.91 References: <001701c50624$43f8df20$2101a8c0@computername> <41FD0418.1030703@gmx.net> In-Reply-To: <41FD0418.1030703@gmx.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1285927.ZlcRlxB4EH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501301710.20212.zander@kde.org> X-SW-Source: 2005-q1/txt/msg00015.txt.bz2 --nextPart1285927.ZlcRlxB4EH Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-length: 2116 On Sunday 30 January 2005 16:58, Robert Schuster wrote: > Hello Audrius, > AFAIK a solution that allows JUnit tests being run as part of mauve is > frequently discussed here but there was no result yet. > > Former discussions could IMHO not solve this problem: > JUnit uses reflection and therefore depends on a stable support for this > mechanism. Mauve as a framework for testing the basic functionality of a > VM could therefore not depend on a working reflection API. > > Despite from that I like the idea of faking a JUnit environment to run > such tests. However that environment should be created with only minimal > dependency on the VM. > > My suggestion is that for each testcase TC you have to: > * scan the class file of TC with something like javap > * generate Java source code that calls the public methods of TC, > call that an adapter class AC > * compile the AC > * run the mauve test via the AC I had the same idea; let AC implement the right mauve-structures (the=20 Testlet interface) and you will have a runnable test environment. If javap is too big a dependency; then it is also possible to generate the= =20 AC class using reflection. This means you have to write a class that gets= =20 a list of fully-qualified class-names and then uses reflection much like=20 JUnit does. Only instead of running the tests you write out a Testlet for= =20 that class. This would fit nicely with a project I am (still) working on. I intend to=20 create one jar file with all the mauve tests and anyone can then use that=20 jar to execute each test on their own JVM. This fits because I doubt we=20 want the generated wrapper classes in CVS and I will surely compile/jar=20 using the Sun JVM. The biggest problem I see with this is that the mauve toolkit will only=20 compile/run with JUnit in the classpath. Perhaps some stubs can also be=20 supplied to counter this problem. As Robert said; many have stated that this is a good idea, but nobody reall= y=20 supplied any code to actually do it :) Looking forward to any proof-of-concepts from you!! --=20 Thomas Zander --nextPart1285927.ZlcRlxB4EH Content-Type: application/pgp-signature Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB/QbsCojCW6H2z/QRAuNIAKC2WLdpWCSiYkMfUNFHfmSYwHDD6QCgzp+U fMHwTyuvwwih9uiYpOWAwQo= =0UsW -----END PGP SIGNATURE----- --nextPart1285927.ZlcRlxB4EH--