[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Diff lib

From: <rbb_at_rkbloom.net>
Date: 2003-01-10 16:00:32 CET

On Fri, 10 Jan 2003, Joe Orton wrote:

> On Thu, Jan 09, 2003 at 02:05:45PM -0500, Garrett Rooney wrote:
> > >Sounds great... but does this mean importing another testing framework
> > >into the svn tree?
> > >
> > >(We already have two: a simple C and simple python framework. We use
> > >the C framework to directly test libsvn_* APIs, and we use the python
> > >framework to test the 'svn' commandline client.)
> >
> > from the little playing around i've done with CuTest in the apr unit
> > tests, i've been quite impressed with it. that said, i haven't done
> > much with our existing C unit test framework, so i don't know how they
> > compare.
> I don't find much to recommend CuTest - it uses longjmp/setjmp rather
> than just functions returning values (questionable at best), and can't
> print test results and failure messages as they're generated, which is
> particularly annoying.

The second part is on my list to fix. As for the longjmp/setjmp, I also
consider that questionable, but when I tried digging in to change it, I
changed my mind. The problem is that once the first check in a test
fails, any other check that you do is really useless. So, stopping the
test after the first failure makes sense. If you don't use
setjmp/longjmp, then either the tests themselves need to account for this,
or the test suite needs to enter each check, test if a previous one
failed, and return if it did. That is doable, but mildly ugly.

BTW, if I migrate the Subversion system to CuTest, it will no longer be
named CuTest. I feel really bad forking the project and using the same
name, so I will be renaming my fork of CuTest.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 10 15:47:11 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.