----- Original Message ---- > From: Marvin Humphrey <[email protected]> > To: [email protected] > 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.
