This is the mail archive of the
mailing list for the Mauve project.
Re: Discussing a helper class to migrate from JUnit
- From: Robert Schuster <theBohemian at gmx dot net>
- To: mauve-discuss at sources dot redhat dot com
- Date: Sun, 30 Jan 2005 16:58:16 +0100
- Subject: Re: Discussing a helper class to migrate from JUnit
- References: <001701c50624$43f8df20$2101a8c0@computername>
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
These are only basic thoughts.
Meskauskas Audrius wrote:
Following the rules of the Mauve project, I would like to discuss the
following addition to Mauve before submission:
JUnit is another popular testing suite. Some people may already have a
JUnit tests written and need to adapt them for Mauve. Some code
generators produce tests for JUnit and not for Mauve. In this context,
it seems good to have an additional helper class for easier conversion
of JUnit TestCase into Mauve Testlet. It is possible to have the
individual helper class as a part of the test itself. However it may
be better to have it in a more public place where it could be shared.
1. The JUnit TestCase calls static methods like assertTrue(..),
assertEquals(..) and so on. The helper class can have the identically
named non-static methods, just delegating the call to the current
instance of TestHarness.
I think that the helper class to live in the same package as the real
2. The JUnit TestCase has a multiple public non static parameterless
methods, starting with test.... These methods are found and called
using reflection. The helper class can do just the same.
IMHO reflection is considered high-tech which may be broken/unsupported
on a VM.