Discussing a helper class to migrate from JUnit

Discussing a helper class to migrate from JUnit

[Meskauskas Audrius]

Hello,

Following the rules of the Mauve project, I would like to discuss the 
following addition to Mauve before submission:

Motivation:
 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.

Suggestion:
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.

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.

3. The two protected methods, setUp() and tearDown(), should be present in a 
helper class as they are frequently
called from the generated code. These two methods can return without action 
for beginning.

The class, implementing these two things, would allow to run a typical JUnit 
test on Mauve with only minor changes.

If no suggested otherwise, the class could be called Unitizer and placed 
into gnu.testlet.

Regards

Audrius

Re: Discussing a helper class to migrate from JUnit

[Robert Schuster]

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

These are only basic thoughts.


Meskauskas Audrius wrote:

> Hello,
>
> Following the rules of the Mauve project, I would like to discuss the 
> following addition to Mauve before submission:
>
> Motivation:
> 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.
>
> Suggestion:
> 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 
JUnit classes.

>
> 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.


cu
Robert

Re: Discussing a helper class to migrate from JUnit

[Thomas Zander]

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

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 
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 
AC class using reflection.  This means you have to write a class that gets 
a list of fully-qualified class-names and then uses reflection much like 
JUnit does.  Only instead of running the tests you write out a Testlet for 
that class.

This would fit nicely with a project I am (still) working on. I intend to 
create one jar file with all the mauve tests and anyone can then use that 
jar to execute each test on their own JVM.  This fits because I doubt we 
want the generated wrapper classes in CVS and I will surely compile/jar 
using the Sun JVM.

The biggest problem I see with this is that the mauve toolkit will only 
compile/run with JUnit in the classpath.  Perhaps some stubs can also be 
supplied to counter this problem.

As Robert said; many have stated that this is a good idea, but nobody really 
supplied any code to actually do it :)
Looking forward to any proof-of-concepts from you!!

-- 
Thomas Zander

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]