lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: [lucy-dev] C TAP test harnesses
Date Fri, 13 May 2011 18:33:55 GMT
----- Original Message ----

> From: Marvin Humphrey <marvin@rectangular.com>
> To: lucy-dev@incubator.apache.org
> Sent: Fri, May 13, 2011 2:17:44 PM
> Subject: Re: [lucy-dev] C TAP test harnesses
> 
> On Thu, May 12, 2011 at 09:59:47PM -0700, Joe Schaefer wrote:
> > FWIW the  features in the apreq stuff that are nice for me are
> > 
> > 1) macros  provide access to __FILE__ and __LINE__ in the test source file,
> 
> It's  definitely nice having access to __FILE__ and __LINE__.  The  
Charmonizer
> tests don't include them because we prioritized taking variadic  arguments for
> the test label.  We couldn't keep that feature and include  __FILE__ and
> __LINE__ implicitly without requiring variadic macro support  from the
> compiler.
> 
> From what I can tell, you made the opposite choice  in the apreq harness -- 
you
> support __FILE__ and __LINE__, but you only  accept simple string test labels. 

> 
> If we were to change the Lucy test  harness to use __FILE__ and __LINE__
> implicitly, we would also have to modify  some number of tests by creating
> pre-formatted test labels locally to pass  into the TEST_XXXXX() routines.  
> A starter patch incorporating the  necessary changes to TEST_TRUE() is below 
my
> sig.  (It does not include  fixes for the 22 incompatible variadic invocations
> of  TEST_TRUE().)
> 
> > 2) skip lists, todo lists, and fatals are  supported.
> > 
> > 3) there is a localizer which allows you to next  test frameworks.  it 
>basically
> > supplies its own harness and treats  all subtest errors as fatal- handy if
> > you're running a tight loop of  tests and really aren't interested in 
feeding
> > all that data directly to  stdout.
> 
> These are great, too.   Our existing test harnesses have  only a crude
> mechanism for skipping tests, and no support for TODO tests or  subtests.
> 
> > The apr dependency is just because apreq has a core  dependency on apr, so 
>why 
>
> > not.
> 
> Whoa, if the apreq harness can  work without APR that would be sweet.  I 
looked
> at at.c and I see that  it makes heavy use of apr_snprintf().  Can you fall
> back to sprintf()  safely?

Haven't looked closely, but I don't see a priori why the stdlib's formatting 
functions
can't be used effectively here.
 
> > It could be dropped without much effort, or these features  added to the
> > existing Lucy C test apparatus.
> 
> Would apreq accept  patches removing the APR dependency?  And is at.h a public
> API?   Ideally, we would want to bundle those files and use them  verbatim.
> Maintaining our own fork for the sake of Charmonizer's tests is  less
> desirable, unless we decide we want to go all out and publish a  supported C
> TAP library ourselves.

Yes, of course that would be accepted/encouraged in apreq.  (The at.[ch] stuff
is also designed to work within an httpd server C module (tho we don't make use
of it in apreq) where the TAP output is sent out over HTTP.)  Getting rid of
the apr dependency would be a welcome change, so long as we're careful to
avoid leaks.

Mime
View raw message