This is the mail archive of the mauve-discuss@sources.redhat.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: request for comments (long)


Hi,

On Wed, 2002-12-11 at 10:27, Raif S. Naffah wrote:
> [...]
> finally because it's simpler to learn and use, considering how little 
> (feature-wise) we need/use from JUnit. Mauve, in constrast, is few 
> classes, 1 README and off you go.  i believe there's a place for such a 
> light-weight testing framework.

This is why I like the Mauve framework. It is small and simple and JUnit
sometimes uses trickery (reflection) to do its work.

> >> IV. the mechanics of configuring Mauve, and GNU Crypto, are
> >> complicated...
> >> another approach is to import the Mauve base classes and
> >> scripts into GNU Crypto, and handle the lot with the same
> >> toolchain.  the problem with this approach is that every time
> >> an enhancement is made to Mauve, the same has to be adopted for
> >> its twin in GNU Crypto...
> >> is there a better way that we can use today?
> >
> > Maybe not :-(.  We're definitely open to suggestions and patches
> > improving the situation.
> >
> > For libgcj we just have our test harness run Mauve's own configure
> > and build.  However, as you point out this is a pain since the test
> > code is a different project which must somehow be pointed to.
> 
> understand.  i'm after something as simple as that too :-)  putting the 
> gnu.crypto.xxx test classes under the gnu.testlet folder, amending the 
> 'choose' script, and Makefile.am to use a $(project_so) seem to do the 
> job.  i'll wait and see if others suggest different alternatives/ideas 
> before deciding which way to jump.

But I don't like Mauves configury/setup magic. Note that I once made
some scripts that make using Mauve simpler (when you have a GNU system
with bash).
See: http://sources.redhat.com/ml/mauve-discuss/2002-q3/msg00019.html

If these seem useful to you then I can import them into Mauve. You can
then just use Mauve as upstream provider of your testframework. I
wouldn't worry to much about having two copies of those files in
different CVS trees. Both Mauve and GNU Crypto see active development
but both groups of developers know each other, or are sometimes even the
same people :) And the basic framework doesn't change that much anyway.

It might also be time to make a real Mauve release. This can then be
used as a stable point to test core library implementations against
since now you have to remember which CVS checkout of Mauve you were
testing against last time.

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]