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