Here's a patch for op/avhv.t ro remove the 'print "not "' in bleadperl.
You wanted us to send them to you, not to p5p, right?
--- Joe M.
*** avhv.t Wed Aug 29 10:59:00 2001
--- avhv.t.new Wed Aug 29 10:56:40 2001
***
*** 19,24
--- 19,38
print "1..29\n"
I didn't send the one that uses Test::More, which was really silly because
the one I sent doesn't work (left out one test)!
This patch switches avhv.t to use Test::More; verified under 'make test'
in ./bleadperl, and './perl -I../lib harness', and './perl -I../lib
harness -v' in bleadperl/t.
--
Am I being goofy if I want to fix the stuff that I know is bad even if
it can't be done via an ok() function? I seem to recall that the
print "not " unless something;
print "ok xx\n";
occurs a lot and make VMS all urpy.
I'll look into cleaning that up after doing the ok() insetions. It's
p
Michael G Schwern wrote:
>t/op/flip.t Yes (what is this?)
>
Flip-flop operator, I think.
I'll keep plugging, and thanks for the help.
--- Joe M.
I took the printf(), added an sprintf() and another conditional
operator, and got the following:
my $test = 1;
sub ok {
my($ok, $name) = @_;
printf "%sok %d - %s%s\n", $ok ? "" : "not ", $test, $name,
($ok ? "" : sprintf("\t# Failed test at line %d\n",
(caller)[2]));
$t
I've switched over to using is() for anything that wasn't an '==' test'
on funky
numeric values; there are a lot of those in (e.g.) bop.t, and I didn't
want to
change the fundamental nature of the tests. I've also gotten my diff format
right this time. :)
So here are:
- avhv.t
- bop.t
- cha
Michael G Schwern wrote
>Hmmm. concat.t is wy too basic to use Test::More on it. delete.t
>is pushing it. die.t and die_exit.t cannot be tested with Test::More
>since it relies on that functionality.
>
Okay, not a problem. I can clean up the prints anyway:
print "not " unless some_c
On Sat, 1 Sep 2001, Michael G Schwern wrote:
> > -print "1..11\n";
>
> We kinda needed that. :)
>
ooops. :-*
--- Joe M.
Michael G Schwern wrote:
>On Wed, Aug 29, 2001 at 12:27:40PM -0400, Joe McMahon wrote:
>
>>I didn't send the one that uses Test::More, which was really silly because
>>the one I sent doesn't work (left out one test)!
>>
>
>Ooooh, much better. Test::
> This statement makes my eyes bleed. You don't have to shove them
> together like that. And the "# Failed" should be on a seperate line.
Ah. Thought it should occur in the same line.
> Ok. I'll repatch with the sensible ok() and send this one onto p5p.
Oooh, me first patch. :) Thanks, and I r
On Mon, 17 Sep 2001, Michael G Schwern wrote:
> So I had this bright idea. Test::FAQ and Test::Tutorial are just sort
> of sitting here on my hard drive not doing much of anything. Why not
> put them up as a Wiki and then everyone else can sort of just play
> around with it and we'll see what h
We've found a couple of things. First, we have a "reviewformat" program which
diffs the code vs. RCS, so you have a change-barred version of the code for
the review. Anything with a change bar has to be explained in the review.
Second, anything that hash to be explained during the code review nee
Started on the qa-wiki. First entry: how to return an internal failure
as a proper test failure so that Test::Builder::Tester and Test::Tester
will like it.
--- Joe M.
On Apr 29, 2005, at 12:15 PM, David Wheeler wrote:
So for my next trick, a harness! I have to give some thought for how
to combine a bunch of JS tests into one output. Maybe a JS script that
spawns hidden frames and runs the tests in them, then collects the
output from them (directly from detail
From Schwern's comment:
I'll consider putting in some more information into the
Test::Builder->details so information like the file and line number
where the test occured can be gotten without scraping.
I'd really like to have this as well. Current projects could really use
it.
--- Joe M.
On Oct 5, 2005, at 11:38 AM, Michael G Schwern wrote:
I'm done talking about this until I see some attempt at fixing
Test::Builder::Tester. It could have been done by now.
I'll do it tomorrow unless someone else already has.
--- Joe M.
PS: As an example of something I'd like to see 'cleaned up' in TAP --
I have a lifelong aversion to 'syntactic comments', i.e., comments
that actually have a meaning to something parsing them. Accordingly,
I'd love to see "not ok 2 # TODO bend space and time" become "todo 2 #
bend space and ti
Here's a scenario we have here at Yahoo!.
The code we're testing depends on XML feeds from backend servers, which
may sometimes be overloaded and not respond. The frontend servers work
around this, but it would be better if we could fail a test, wait a
bit, then go back and run it again a f
Want: This
Have: That
Put me down for this one too. Simpler for non-English speakers as well.
On Jul 11, 2006, at 7:34 AM, Ian Langworth wrote:
Maybe we don't care. Maybe we can simply add a callback for some
diagnostic_block_analyzer() and, in my own little happy world,
$parser->diagnostic_block_analyzer( sub {
my ($block) = @_;
if ($block =~ m{ \A --- }xs) {
do something
I will never get used to mailing lists that don't default to "reply
all"...
Begin forwarded message:
From: Joe McMahon <[EMAIL PROTECTED]>
Date: July 21, 2006 11:43:31 AM PDT
To: A. Pagaltzis <[EMAIL PROTECTED]>
Subject: Re: Test::More, BEGIN use_ok, plan, what?
On Jul 21, 2006, at 12:25 PM, Tyler MacDonald wrote:
Andy Lester <[EMAIL PROTECTED]> wrote:
How about a stripe for this shit?
http://search.cpan.org/src/SKNPP/Chest-0.082/lib/Chest.pm
Kwalitee metric: "Package does not depend on Chest.pm". ;-)
I was thinking "Author is not batshit insane"
On Aug 15, 2006, at 11:29 AM, Michael Peters wrote:
I think this is the most important benefit. Test runs aren't bound
to the single
time it was run with a certain harness. They can be captured and
viewed later by
the same developer or shared among developers. If the report is
descriptive
e
In short, many of the gripes of the Perl community about the known
limitations of our testing framework could be mitigated if can get
momentum on this again. However, OSCON just ended, Schwern has a
new job, Andy has other (good) projects that he's pursuing and work
here has stalled. I
Here's an example of why TAP is a good way to go for testing.
Here at Yahoo! we run a *lot* of tests to see if our stuff is working
right. Not only do we test the mainline code, but we also test variants to
see which ones the users like better, or help get better targeted ads in
the paid searc
On Wed, 6 Sep 2006, Michael G Schwern wrote:
Additionally, if you're going to keep this thing around, restricting the
examples to .pl files penalizes HTML (Mason or other templating system), POD
and module examples. [1] It would be best to just say that the directory
contains something.
Yep.
On Feb 2, 2007, at 1:47 AM, Adrian Howard wrote:
and then parse it out with TAPx::Parser and friends. I believe a
guy from Yahoo did something similar - can't remember if the code
ever escaped though...
That's Tester, which uses imaginary test numbers to denote included
tests.
ok 1
ok 2
o
On Feb 2, 2007, at 2:03 AM, Ovid wrote:
I don't recall seeing it on the CPAN, but as I recall, he was doing
stuff
like this:
ok 1 - [gui][database] fribble cleared
ok 2 - [database] - bar set
ok 3 - [gui] - widget bobbling
ok 4 - [gui][critical] - finkle barbed correctly
And that's
On Aug 31, 2008, at 7:58 AM, David Golden wrote:
On Sat, Aug 30, 2008 at 2:40 PM, chromatic <[EMAIL PROTECTED]> wrote:
On Saturday 30 August 2008 05:01:11 David Golden wrote:
You can write "die" on missing prerequisites if you want, as long as
you realize that CPAN Testers can't tell that fro
29 matches
Mail list logo
