--- /-\ 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
--- 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
--- "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
On Tue, Dec 07, 2004 at 01:46:26PM -0800, Ovid wrote:
> I thought some of you might find this of interest and then I realized
> that a Test::Cookbook might be useful.
There is a Test::FAQ sitting unreleased in the Test-Simple repo.
http://svn.schwern.org/svn/CPAN/Test-Simple/trunk/lib/Test/FAQ.p
> > > 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
I thought some of you might find this of interest and then I realized
that a Test::Cookbook might be useful. Here's a problem I recently
faced and how I solved it:
Problem:
POD is incomplete in a module but you still want to test POD coverage
with something like Test::Pod::Coverage::all_pod_cove
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or preserves them) or a
> I'm wondering if I'm the only one who would love to see
> Devel::Cover::Regex? [...] I think this would be a very useful
> extension to Devel::Cover, although I imagine that it's pretty tricky
> to do. Even figuring out how to display the results might be tough
> to do well.
It's not a solution
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Tuesday 07 December 2004 20:33, Kevin Scaldeferri wrote:
> I'm wondering if I'm the only one who would love to see
> Devel::Cover::Regex? Many (most?) perl programs are pretty regex
> heavy, and if we are honest with ourselves, we have to admit that ea
I'm wondering if I'm the only one who would love to see
Devel::Cover::Regex? Many (most?) perl programs are pretty regex
heavy, and if we are honest with ourselves, we have to admit that each
regex is actually a program in itself. You can try to throw lots of
inputs at it and hope that you we
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or preserves them) or
--- Andy Lester <[EMAIL PROTECTED]> wrote:
> Q&D way would be to confess.
>
> is( $nstooges, 3 ) or confess;
Yes, that works, but when I am doing heavy development on a bunch of
new code, it's nice to have generic hooks in place to handle such
issues even if I don't know before hand which tests
--- Tim Bunce <[EMAIL PROTECTED]> wrote:
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not o
On Tue, Dec 07, 2004 at 09:32:37AM -0800, Ovid ([EMAIL PROTECTED]) wrote:
> Is there is anything in the Test::* hierarchy that allows callbacks to
> be triggered on test failures? It would be nice to pass a sub that
> automatically dies on warnings, prints stack traces, cleans up temp
> files (or
On Tue, Dec 07, 2004 at 12:48:01PM +, Tim Bunce ([EMAIL PROTECTED]) wrote:
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - should be red
I always write tests and
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - sho
Is there is anything in the Test::* hierarchy that allows callbacks to
be triggered on test failures? It would be nice to pass a sub that
automatically dies on warnings, prints stack traces, cleans up temp
files (or preserves them) or any of a number of things that I'd like to
be able to handle.
On Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
> or
> ok( $expr, "comment" );
> is
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" because it impli
I don't really agree that "comment" implies "not really worth doing". I
think
those inclined to not put a name/comment/label on their test will not
do it
whatever we end up calling it. IMO the only way to get people to do it
would
be to make it required, and I don't think that is a good idea.
I
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
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 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
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 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: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 Mon, Dec 06, 2004 at 10:28:45PM -0600, Andy Lester wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
>
> RJBS points out that "comment" implies "not really worth doing", and I
> still don't like "name" beca
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
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
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
On Tue 07 Dec 2004 05:28, Andy Lester <[EMAIL PROTECTED]> wrote:
> I think even better than
>
> ok( $expr, "name" );
>
> or
>
> ok( $expr, "comment" );
>
> is
>
> ok( $expr, "label" );
or ok ($expr, "indicator");
or ok ($expr, "tag");
for me the name/comment/label/tag/indicator/... is
30 matches
Mail list logo
