On Mon, 26 Aug 2002, Adrian Howard wrote:
> Can anybody give me a definitive version of when TODO tests started
> working in Test::Harness? From the Changes file I'm currently assuming
> everything after Test::Harness 2.03 inclusive should be okay.
>
> Personally, I would tend towards leaving the
On Tue, 20 Aug 2002, Michael G Schwern wrote:
> +=head2 Other Handy Functions
> +
> +=over 4
> +
> +=item prompt
> +
> +my $value = prompt($message);
> +my $value = prompt($message, $default);
> +
> +The C function provides an easy way to request user input
> +used to write a makefile. I
Run this little script:
use Test::More tests => 10;
use strict;
my $pid;
if ($pid = fork)
{
wait;
ok(1) for 1..10;
}
else
{
exit;
}
And note the annoying "# No tests run!" message that gets printed before
the first "ok" message.
I can't think of any really
On Sat, 30 Mar 2002, Michael G Schwern wrote:
> Doesn't seem to have any effect on the code above, but it does have an
> effect on this:
>
> $ perl -Ilib -MTest::Builder -e '$tb=Test::Builder->new; $tb->plan('no_plan');
>$tb->current_test(10)'
> Modification of non-creatable array value attempte
The changelog says this:
0.42 Wed Mar 6 15:00:24 EST 2002
- Setting Test::Builder->current_test() now works (see what happens
when you forget to test things?)
But if I do this:
perl -MTest::Builder -e 'Test::Builder->new->current_test(10)'
it still blows chunks.
Patch below.
ho
On Sat, 15 Dec 2001, Kurt D. Starsinic wrote:
> > my $foo = Foo->new;
> > ok( defined $foo && $foo->isa('Foo') );
> >
> > which rapidly gets tiresome.
>
> Or ok(UNIVERSAL::isa(Foo->new, 'Foo'));
Under 5.005 it spits out warnings if Foo->new returns undef. Plus you
still don't get an
On Tue, 20 Nov 2001, Tels wrote:
> > If you would prefer to handle the
> > ExtUtils::MakeMaker and ExtUtils::MM_* changes yourself let me know.
>
> You can do it. I'll wait until the dust settles (I wrote tests for routines
> that now get removed, so I am a bit conservative with starting another
On Mon, 19 Nov 2001, Tels wrote:
> * There are a couple of functions I have tests for, BUT:
>
> =item canonpath
>
> No physical check on the filesystem, but a logical cleanup of a
> path. On UNIX eliminated successive slashes and successive "/.".
>
> =cut
>
> [snip
On Tue, 2 Oct 2001, Michael G Schwern wrote:
> You capture the output of 'make test' and manipuate that line
> directly?? Eek!
No, I add extra Perl code to that line to set environment variables and
such. Maybe there's another way to do it but its not exactly like these
things are well documen
On Tue, 2 Oct 2001, Michael G Schwern wrote:
> Any particularly good reason we're showing all that "PERL_DL_NONLAZY"
> noise as part of "make test"? What about just:
I do some weird stuff with that piece to pass data around to my tests.
Sometimes its useful to see it. How about only showing it
On Sun, 30 Sep 2001, Michael G Schwern wrote:
> OH! I thought you were literally using fork(), not running another
> program. Now that makes a little more sense.
Yeah, I realized I should've been clearer after a few exchanges (I'm
slow).
> I suppose the idea here is something like:
>
> sy
On Sun, 30 Sep 2001, Michael G Schwern wrote:
> On Sat, Sep 29, 2001 at 09:12:01PM -0500, Dave Rolsky wrote:
> > > use Test::More tests => 10; # or whatever.
> >
> > Except this needs to printed just once in the parent _before_ any tests
> > are run.
>
&g
On Sat, 29 Sep 2001, Dave Rolsky wrote:
> A. To be able to use Test::More's functions without ever printing a 1..foo
> test header.
And it turns out I also need to suppress all the stuff in
Test::Builder::_ending (I simply bailed at line 838).
So basically, I need an "I know w
On Sat, 29 Sep 2001, Michael G Schwern wrote:
> Have you tried the Test::Builder thing yet? I think you should be
> able to solve your forking problem like so:
Working on it
> use Test::More tests => 10; # or whatever.
Except this needs to printed just once in the parent _before_ any tes
On 29 Sep 2001, Piers Cawley wrote:
> If it's not a dumb question, why are you doing it that way? If you
> were using PerlUnit, aka Test::Unit::TestCase, you could do something
> like:
Why am I doing what? Forking and starting tests at weird offsets?
The forking is cause I need to load differe
On Wed, 26 Sep 2001, Michael G Schwern wrote:
> Uggg. No, there's no good way to handle this now unless there's some
> way $Num_Tests can make itself shared between forks.
Well, I do keep track of it in my code and pass it around between forks.
What I need is a way to set it.
> In the general
For my Alzabo tests, I do some weird stuff involving forking off processes
during tests and running the same (basically same) set of tests multiple
times, each time with different modules loaded. The parent process
calculates how many tests will be involved in each run and how many runs
will occu
On Tue, 25 Sep 2001, chromatic wrote:
> Combining the two gives us a test and a very contrived test failure output:
>
> isa_ok($foo, 'Alzabo::Foo', 'Return value from $bar->foreign_keys');
>
> not ok 1 - $foo->isa('bar')
> # Failed test (foo.plx at line 3)
> # Retu
On Tue, 25 Sep 2001, Michael G Schwern wrote:
> A, ok. How about this:
>
> my $yarrow = Bar->new;
> isa_ok($yarrow, "Bar", 'yarrow');
>
>
> not ok 1 - yarrow->isa('bar')
> # Failed test (foo.plx at line 3)
> # yarrow isn't a 'Bar'
That's better, I guess. But I'm
On Tue, 25 Sep 2001, Kirrily Robert wrote:
> But it does! It says something like:
>
> not ok 23
> # Failed test 1 (eval.t at line 69)
> # got: 'blah blah blah'
> # expected: ''
Oops, that's what I get for not actually trying it out.
I guess that's good enough, though I still l
On Mon, 24 Sep 2001, Michael G Schwern wrote:
> On Mon, Sep 24, 2001 at 06:42:55PM -0500, Dave Rolsky wrote:
> > +sub eval_ok (&$) {
> > +my ($code, $name) = @_;
> > +
> > +eval { $code->() };
> > +if ($@) {
> > + ok( 0, "$n
On Mon, 24 Sep 2001, Michael G Schwern wrote:
> On Mon, Sep 24, 2001 at 06:23:58PM -0500, Dave Rolsky wrote:
> > The patch below allows you to supply your own test name for the isa_ok
> > function (I find the default insufficiently descriptive). I'd like to do
> >
Ok, forget the last patch. This one incorporates that plus more.
This one also adds an eval_ok function. The idea here is that sometimes
you simply want to try something to see if it works or not. If it fails
it will append the error ($@) after the name of the test.
The reason for these patch
The patch below allows you to supply your own test name for the isa_ok
function (I find the default insufficiently descriptive). I'd like to do
the same for can_ok but I don't think that could be done without breaking
backwards compatibility.
-dave
--- More.t~ Wed Sep 5 19:23:24 2001
+++
24 matches
Mail list logo
