From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4032 invoked by alias); 30 Jan 2005 15:59:34 -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 4007 invoked from network); 30 Jan 2005 15:59:28 -0000 Received: from unknown (HELO mail.gmx.net) (213.165.64.20) by sourceware.org with SMTP; 30 Jan 2005 15:59:28 -0000 Received: (qmail invoked by alias); 30 Jan 2005 15:59:27 -0000 Received: from p213.54.217.126.tisdip.tiscali.de (EHLO [213.54.217.126]) (213.54.217.126) by mail.gmx.net (mp019) with SMTP; 30 Jan 2005 16:59:27 +0100 X-Authenticated: #17532834 Message-ID: <41FD0418.1030703@gmx.net> Date: Sun, 30 Jan 2005 15:59:00 -0000 From: Robert Schuster User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.7.5) Gecko/20050107 MIME-Version: 1.0 To: mauve-discuss@sources.redhat.com Subject: Re: Discussing a helper class to migrate from JUnit References: <001701c50624$43f8df20$2101a8c0@computername> In-Reply-To: <001701c50624$43f8df20$2101a8c0@computername> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-SW-Source: 2005-q1/txt/msg00014.txt.bz2 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