On Thu, 15 Feb 2001, barries wrote:
> What do folks think of adding something like the following to Test.pm:
>
>my $tname ; ## ok(), skip(), todo() can get the test name from here
>my $is_todo ; ## ok() could look at this and adjust it's output
>
>sub do_all_tests {
> plan tests
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
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, 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 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 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 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 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 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 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 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 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
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 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, 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
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
+++
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
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
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
> >
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
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, 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
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 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
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 Mon, 20 Oct 2003, Andrew Savige wrote:
> I noticed in Test::Tutorial:
> "Taint mode is a funny thing. It's the globalest of all global features.
> Once you turn it on it effects all code in your program and all modules
> used (and all the modules they use). If a single piece of code isn't
> tai
On Mon, 20 Oct 2003, Michael G Schwern wrote:
> On Tue, Oct 21, 2003 at 12:24:03AM -0500, Dave Rolsky wrote:
> > On Mon, 20 Oct 2003, Andrew Savige wrote:
> > > I noticed in Test::Tutorial:
> > > "Taint mode is a funny thing. It's the globalest of all global f
On Tue, 21 Oct 2003, Michael G Schwern wrote:
> On Tue, Oct 21, 2003 at 12:34:44PM -0500, Dave Rolsky wrote:
> > Anyway, my taint mode experience has been that random things break in very
> > weird ways when using it.
>
> All the more reason to test with it on. :)
At t
On Mon, 17 Nov 2003, darren chamberlain wrote:
> * Andrew Savige [2003-11-15 14:51]:
> > I took a quick look a mod_perl and Template Toolkit (TT).
> > TT has a:
> > lib/Template/Test.pm
> > which looks wrong to me (should that not be under t/lib instead?).
>
> Template::Test contains a bunch of
On Mon, 17 Jan 2005, Andy Lester wrote:
Msql-Mysql-modules
This is just the old distro that contained DBD::mysql and DBD::msql. I
don't think the latter is maintained, and DBD::mysql is already on the
list.
-dave
/*===
VegGuide.Org
On Mon, 5 Sep 2005, Thomas Klausner wrote:
has_perl_dependency:
In the META.yml (assuming it exists) there is a dependency on the
version of perl required to install the dist.
The goal of this is to make life a little easier on installers and CPAN
testers and a few other things.
Many many mod
On Mon, 11 Sep 2006, David Golden wrote:
* test.pl vs t/*.t
* Custom Makefile.PL or Build.PL that affects test runs
* build_requires modules bundled in inc/
And don't forget that some tests may include tests data that is needed to
run the tests. If we're lucky, it's under t/
-dave
/*=
This is a combo library/script that is designed to do automated smoke
tests on multiple "test sets" (in my case, branches of a code base). It
has hooks for pushing reports into Smolder, and it has infrastructure in
place so someone could write something to send emails of test results as
well.
On Tue, 11 Dec 2007, Edwardson, Tony wrote:
Anyone written any CPAN modules for which the testing coverage needs to be
improved ?
Oh, yes.
Want someone else to sort this out for you ?
Yes.
Milton Keynes PM want to start working together to contribute to the Perl
development effort and a
On Wed, 19 Dec 2007, Andy Armstrong wrote:
His view: cpan-testers are incompetent, ego tripping, quasi-religious
nuisances.
I think there's some truth to this view.
For support I submit this bug ticket -
http://rt.cpan.org/Ticket/Display.html?id=27208
On the other hand, that was an exceptio
On Thu, 20 Dec 2007, David Golden wrote:
On Dec 20, 2007 1:19 PM, Dave Rolsky <[EMAIL PROTECTED]> wrote:
It's generally
pretty rare that the failure report includes enough information for me to
do anything about it, so without an engaged party on the other end, it
really is just no
On Thu, 20 Dec 2007, Ovid wrote:
To summarize what I think Imacat's point is: some CPAN testers quite
deliberately have only core modules installed in order to catch issues
just like this. As a result, anything which assumes a non-core module
(like your Makefile.PL previously assuming Module::
On Sat, 22 Dec 2007, Andreas J. Koenig wrote:
On Sat, 22 Dec 2007 14:22:05 +0100, [EMAIL PROTECTED] (Andreas J. Koenig) said:
> 1. You get a fail report with an error message that doesn't tell you
>exactly what went wrong.
> 2. You rewrite your test in a way that it does tell you more.
On Fri, 14 Mar 2008, Matisse Enzer wrote:
I'm discussing some potential refactorings at $work at wanted to give an
articulate explanation of the benefits of having package declarations match
file names, so that:
# file is Foo/bar.pm
package Foo::Bar;
One reason is so that when you see a "p
On Wed, 3 Sep 2008, David E. Wheeler wrote:
http://cpantesters.perl.org/author/DWHEELER.rss
This makes it easy for me to sift through things. The only thing that would
make it better is if I could get it to display only FAILs. To whom should a
feature request be sent (I thought I sent a patch
On Fri, 5 Sep 2008, Aristotle Pagaltzis wrote:
* chromatic <[EMAIL PROTECTED]> [2008-09-05 19:50]:
If I could see somehow that my distribution implicitly runs on
Perl 5.001 (or explicitly runs only on 5.11.0), or that it has
no Makefile.PL or Build.PL, or any of the other dozens of
packaging qu
41 matches
Mail list logo
