Keeping in mind I'm not a C programmer so my user expectations may be
all wrong.
On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
> Then you have one of ok() or ok2() at your disposal. ok()'s first parameter
> is the code to test. The second parameter is the test name. This is a
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Why add that extra auto-sprintf complexity? Can't the user do the exact
> same thing with:
>
> ok(some_func(i), sprintf("some_func(%d)", i));
No. sprintf in C needs a buffer and you don't know how big to make it.
> > ok2() is for situatio
On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote:
> --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > Why add that extra auto-sprintf complexity? Can't the user do the exact
> > same thing with:
> >
> > ok(some_func(i), sprintf("some_func(%d)", i));
>
> No. sprintf in C needs
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 06, 2004 at 02:25:42PM -0800, Andrew Savige wrote:
> > --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > > Why add that extra auto-sprintf complexity? Can't the user do the exact
> > > same thing with:
> > >
> > > ok(some_func(i
--- "Clayton, Nik" <[EMAIL PROTECTED]> wrote:
> Having done the initial work to get most of FreeBSD's regression testing
> infrastructure producing Test::Harness TAP compatible output, I've started
> putting together a C library that makes it easier to write tests in C.
Great!
This is something I
On Tue, Dec 07, 2004 at 12:55:01PM +1100, Andrew Savige wrote:
> 3) Implementing cmp_ok() in C is a challenge. ;-)
>
> xUnit/cutest have things like:
>
> AssertStrEquals
> AssertIntEquals
> ...
>
> The trouble with plain old ok() is that investigating test failures
> is a pest. I suppose you cou
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Yucko.
>
> Test::More implements cmp_ok() using an eval. Could a macro prove useful
> here to do something similar?
>
> cmp_ok(foo, 'int', '==', bar);
Good idea Schwern.
These test suites inevitably degenerate into macro crack-pipe
smoking ses
On Tue, Dec 07, 2004 at 03:18:17PM +1100, Andrew Savige wrote:
> Good idea Schwern.
> These test suites inevitably degenerate into macro crack-pipe
> smoking sessions. Lacking 'eval', it is always going to be very
> hard work to even get close to Perl's Test::More functionality
> and ease-of-use in
Michael G Schwern wrote:
> On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
>> Then you have one of ok() or ok2() at your disposal. ok()'s first
>> parameter is the code to test. The second parameter is the test name.
>> This is a printf()like format string, and the third and subsequ
Michael G Schwern wrote:
>> An alternative is to drop the ugly ok2() and force the test writer to
>> use:
>>
>> ok(1 == 2, "");
>>
>> I prefer that since I want to make it hard for people to avoid giving
>> a test a name, er, comment.
>
> At the very least some better name than ok2().
Na
Andrew Savige wrote:
> 1) You might be able to steal some implementation ideas from:
>
> http://cutest.sourceforge.net/
>
> This is a very simple C Unit Testing framework.
> In particular, it keeps state in a CuTest struct which is passed
> around as the first (mostly hidden) parameter to most fu
On Tue, Dec 07, 2004 at 09:11:06AM -, Clayton, Nik wrote:
> > At the very least some better name than ok2().
>
> Name suggestions gratefully received. I wanted something short, to make
> it easier than "ok(1 == 1, "");", and ok2() fits in with the historical
> naming of functions like wait(),
On Tue, Dec 07, 2004 at 09:07:36AM -, Clayton, Nik wrote:
> There's no way to tell from the first argument whether or not the second
> argument exists. If it doesn't exist you can't even safely check for its
> existence.
>
> To give a printf() example, something like this:
>
> int n = 42
On Tue, Dec 07, 2004 at 09:21:32AM -, Clayton, Nik wrote:
> Andrew Savige wrote:
> > If so, you better think about it now because it's very hard to retrofit.
>
> Any "Writing thread safe libraries for dummies" texts you could point me
> at?
Apart from the ones that say "run away screaming?"
On Tue, Dec 07, 2004 at 11:46:24AM +, Dominic Mitchell wrote:
> What does it mean to run the test in multiple threads anyway? What are
> those other threads doing? I can see someone running code in a separate
> thread, but I can't imagine running the TAP stuff in more than one
> thread.
Mayb
Michael G Schwern writes:
> On Tue, Dec 07, 2004 at 09:11:06AM -, Clayton, Nik wrote:
> > Name suggestions gratefully received. I wanted something short, to make
> > it easier than "ok(1 == 1, "");", and ok2() fits in with the historical
> > naming of functions like wait(), wait2(), wait3(), w
On Dec 7, 2004, at 4:07 AM, Clayton, Nik wrote:
Michael G Schwern wrote:
On Mon, Dec 06, 2004 at 10:00:32AM -, Clayton, Nik wrote:
Then you have one of ok() or ok2() at your disposal. ok()'s first
parameter is the code to test. The second parameter is the test
name.
This is a printf()like for
> > > I hope you're not emulating Test::More's exit code == # of
> > > tests failed "feature" that I'm planning on getting rid of.
> >
> > Right now that's exactly what I'm doing. The test suite for libtap
> > consists of a series of Test::More test files and a series of C files that
> > try and
--- "Clayton, Nik" wrote:
> Andrew Savige wrote:
> > 2) A uniform mechanism for test programs to handle command line
> > arguments would be nice. For example:
> >
> > int main(int argc, char* argv[])
> > {
> > tap_init(argc, argv); /* mythical new tap function */ // ...
> > }
> >
> > So
--- muppet wrote:
> writing your own printf-style macros is actually a very common idiom
> for getting around this sort of technical problem. they, of course,
> raise the further problem that GCC's vararg macros are not portable,
> and C99's vararg macros are not yet universally supported.
Ag
--- /-\ wrote:
> In an attempt to do varargs ok() without the magical __VA_ARGS__,
> I've come up with two little example solutions shown below.
> Improvements welcome.
Sorry, but curiosity got the better of me and I took a look at how
the very widely used and portable C++ ACE library does it.
Th
On Dec 7, 2004, at 9:25 PM, Andrew Savige wrote:
/* Horrible hacky thread-unsafe version but no XX */
...
static const char* g_file;
static unsigned long g_line;
i forgot to mention, the way around the non-thread-safety here is to
use thread-local storage.
c.f. pthread_key_create() and p
Clayton, Nik wrote:
>> You might want to throw it in as an option. I'm going to change
>> Test::More so it no longer mucks with the exit code by default, you'll
>> have to turn this feature on.
>
> OK. I'll track changes to Test::Harness, and libtap'll stop
> doing it when T::H stops.
Or, more
--- "Clayton, Nik" wrote:
> Any "Writing thread safe libraries for dummies" texts you could point
> me at?
I recommend "Programming with POSIX Threads" by David Butenhof.
Re the varargs ok() business, I assume you'll be using some sort of
config.h with your libtap library. Any plans on using aut
> --- "Clayton, Nik" wrote:
> > Any "Writing thread safe libraries for dummies" texts you
> > could point me at?
>
> I recommend "Programming with POSIX Threads" by David Butenhof.
Thanks.
> Re the varargs ok() business, I assume you'll be using some sort of
> config.h with your libtap library
25 matches
Mail list logo
