Andy Armstrong wrote:
> On 4 Sep 2007, at 22:41, Ovid wrote:
>>> What do you think of this?
>>> http://testanything.org/wiki/index.php/TAP_datetime
>>
>> Works for me.
>
> Yup, looks fine.
Maybe we should start noting this on the wiki? Sign proposals with a
(Mediawiki signature).
http://te
Gabor Szabo wrote:
> I would like to compare data structure in some non-test code.
> Test::Deep seems to give all the features I need, except that it is
> integrated with
> the testing framework.
>
> How could I use that or what else should I use to compare two deep
> data structures?
Here's how
Michael Peters wrote:
> Ovid wrote:
>
>> Thanks for reminding me. Another bit of meta-information that should
>> be optionally supported in the TAP YAML output is "duration". If one's
>> comparing the behavior of a test suite over time, some might find it
>> beneficial to know that they've added
A. Pagaltzis wrote:
>> If they're really not useful and just complicate matters I'm
>> quite open to being convinced otherwise.
>
> OK; the goal here, I think, is to make TAP as simple as possible
> to generate as well as consume, without limiting expressiveness
> unnecessarily.
Yep, we're on the
A. Pagaltzis wrote:
> I don’t think you’re overly conservative when it comes to app
> data, but I agree with Ovid that this is bad separation of
> concerns. How dates in app data are handled should be up to the
> app to define. I think we should restrict this proposal solely to
> datetimes in TAP m
A. Pagaltzis wrote:
> SHOULD is costly and should be avoided in favour of MUST or MAY
> wherever possible – we had this discussion we had frequently in
> the Atom WG. Over time, given enough implementations, any given
> SHOULD tends to be treated as either a MAY or a MUST anyway.
>
> That reasonin
Ovid wrote:
> Whoa! I missed a memo and now I'm confused. I did think that a lot of
> this fuss over the date YAML meta information in TAP was going on a
> bit, but small details can be important. However, date YAML diagnostic
> information (we need formal names to distinguish between those two)
Geoffrey Young wrote:
>
> Scott McWhirter wrote:
>> This would be easy to do in Test::Builder within &Test::Builder::ok by
>> making it call $Test->BAIL_OUT();
>>
>> Then at least you would get it across all Test::* modules.
>
> yeah, that's what I was implying in my followup message.
>
> the at
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-09-07 14:40]:
>> I'm down with changing it to MUST for TAP meta and MAY for
>> diagnostics.
>
> Works for me.
Done.
--
Stabbing you in the face for your own good.
Matisse Enzer wrote:
> A side-note to keep in mind: If we every want to be able to convert TAP
> to the XML format produced by the JUnit ant task (this way for example
> CruiseControl could more easily read the results of Perl tests) then it
> becomes desirable to get timing info for each perl test
Andy Armstrong wrote:
> On 8 Sep 2007, at 11:21, Michael G Schwern wrote:
>> Is this a time stamp or the elapsed time for a test? The former is
>> pretty
>> easy, just add to Test::Builder::ok(). The latter is not. Perl tests
>> don't
>> have any clearly
Matisse Enzer wrote:
> There certainly is a mapping problem and I don't have a perfect
> solution, and enabling Perl test output to be understood by
> CruiseControl (for example) is a valuable thing, in my opinion.
Seems to be, knowing nothing about CruiseControl, that rather than trying to
match
Andy Armstrong wrote:
> On 9 Sep 2007, at 22:04, Ovid wrote:
>> As I recall, we've hit the same problem with another module (POE?) and
>> I'm thinking that extending the TAP grammar here might be the key.
>> Specifically, consider this:
>>
>> 1..0 # SKIP some reason
>>
>> The '1..0' is 'skip all'
Michael Kernaghan wrote:
> While you are at it would you care to try to install modules from CPAN
> onto Active Perl running on Vista? It just seems a world of grief;
> although identical installs are great under XP. I just flat gave up
> using Vista for Perl. I feel sad, but what can one do?
I
Thomas Klausner wrote:
> On Mon, Sep 10, 2007 at 11:10:25PM +0200, Anonymous wrote:
>
>> also, would it make sense to have a test to check for warnings
>> when warnings are enabled globally? many modules do not enable
>> warnings, but when you use those modules and run the script
>> with -w, it's
Thomas Klausner wrote:
> I'm not sure if the problem is caused by some dists liek Number::Phone,
> or by Pod::Simple::Checker (YAML for sure is causing the segfaults, but
> I'd definitly want to correct the data, too)
>
> I've put one of the problematic files up here:
> http://cpants.perl.org/st
http://www.pobox.com/~schwern/src/Test-Simple-0.71.tar.gz
The big change here? No more sort_bug.t. Bye bye 90% of my spurious bug
reports. It was testing two deprecated functions and tended to hit bugs in
threaded perls that I can't fix and the user doesn't care about.
I replaced with with a s
Test::More 0.71 fixed a subtle bug where a call to use_ok() inside a BEGIN
block without a plan would be silently ignored. That is...
use Test::More;
BEGIN { use_ok('Exporter') } # for example
plan tests => 1;
pass();
would pass when it should have failed. Thi
Jerry D. Hedden wrote:
> Michael G Schwern wrote:
>> http://www.pobox.com/~schwern/src/Test-Simple-0.71.tar.gz
>
> BTW, when to you plan to submit a patch for this against blead?
Magic p5p fairies usually take care of that.
--
Stabbing you in the face so you don't have to.
Rafael Garcia-Suarez wrote:
> And tests now pass with following change.
> It takes care of
> a/ pushing the right dirs in @INC when running in the perl core test suite
> b/ fixes the $VERSION of Dummy.pm. Apparently bleadperl comes with
> another version of Dummy.pm than Test::Simple don't
This release unfixes a bug. 0.71 fixed a bug where if you ran a use_ok()
inside a BEGIN block without a plan it would silently fail and the test would
continue. For example...
use Test::More;
plan tests => 10;
BEGIN { use_ok("Some::Module") }
It looks like you planned
Ovid wrote:
> --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
>> Because of this I'm TEMPORARILY rolling the fix back at least a week
>> to give
>> CPAN authors a little breathing room to make their fixes. The fix is
>> usually to plan in a BEGIN
Ovid wrote:
> For something as high profile as Test::Simple, it would get much more
> exposure than most modules. Plus, there wasn't much in the changelog
> which suggested this was a rush OMG Must Deliver Now sort of change (it
> had been six months since the last release).
I get a bug up my ass
This week's Perl 5 Wiki topic improvement drive is...
Recommended Modules For Testing
http://www.perlfoundation.org/perl5/index.cgi?recommended_modules_for_testing
Right now there's only TWO modules listed. I know a few people have written
good testing modules out there.
The
David Cantrell wrote:
> Michael G Schwern wrote:
>
>> This week's Perl 5 Wiki topic improvement drive is...
>>
>> Recommended Modules For Testing
>>
>> http://www.perlfoundation.org/perl5/index.cgi?recommended_modules_for_testing
>>
>
Salve J Nilsen wrote:
> - Set up some kind of syndication feed [RSS, Atom] [somewhere sensible]
> where one can read which distributions currently have a "pre-release"
> status. The feed might be called "NEED TESTING" or something like that.
> Make this feed visible on central Perl-related websites
Jonathan Rockway wrote:
> David Golden wrote:
>> On 9/25/07, Chris Dolan <[EMAIL PROTECTED]> wrote:
>>
>>> Well, one option might be something like:
>>>http://www.cpanforum.com/tags/name/helpwanted
>>> Gabor, would it be easy to add an Atom/RSS feed for a particular tag?
>>>
>> Please n
Graham TerMarsch wrote:
> [crosspost from the mod_perl mailing list, at recommendation of others on the
> MP list]
>
> Wanted to ping the list about something that's irked me the last few days...
>
> After recently releasing Apache2::Filter::Minifier::JavaScript/CSS, I saw
> several failed CPAN
Greg Sabino Mullane wrote:
> I just released Bucardo, a multi-master replication system for Postgres.
> It has a fairly intense test suite, and I was developing it, I ended up
> writing Yet Another Test Counter. At some point, I decided to turn it
> into a proper module. Here's the POD page:
>
> h
Zaven Boni wrote:
> Hello list,
>
> My team at Data Domain (NASDAQ: DDUP), the leader in de-duplicating
> storage systems, is looking for an engineer with solid Perl skills as
> well as a system performance measurement and tuning background. We are
> part of the development team which builds the D
Graham TerMarsch wrote:
> As a dumb alternative... what about explicitly listing M::B as a build
> dependency? Would that trigger CPANPLUS into installing it and then
> restarting the build?
I don't know what CPANPLUS does with build_requires. It'll probably balk
about missing CPANPLUS::Dist::
Graham TerMarsch wrote:
> On Wednesday 26 September 2007 3:41 pm, David Golden wrote:
>> I don't think Module::Build can be a build_requires. I think it has to
>> be a configure_requires. (Not that support is widespread yet.)
>>
>> On 9/26/07, Michael G S
Jonathan Rockway wrote:
> Anyway, should the DSLIP stuff be added to the META-spec? (I see that
> some stuff, like the S and L parts, are already covered by META.yml. Is
> the rest worth adding, or is it time to forget about it?)
Something like the DSLIP in purpose, but not exactly DSLIP. That
Greg Sabino Mullane wrote:
> Michael G Schwern asks:
>
>> What's wrong with no_plan? Why go through backflips to
>> automate counting the tests when you can just not count
>> them? Seems needlessly officious.
>
> I seldom run the whole test suite at once, b
Greg Sabino Mullane wrote:
> On Fri, 2007-09-28 at 17:09 -0700, Michael G Schwern wrote:
>
>>> It's also nice to see how far along we are with a running
>>> tally, when I check back in on the running tests.
>
>> How do you accomplish that?
>
>
Andy Lester wrote:
> On Fri, Oct 05, 2007 at 11:22:57AM -0500, brian d foy ([EMAIL PROTECTED])
> wrote:
>> Do you mean that Test::Harness 3.0 won't have it but it will still be
>> there in earlier releases, or that you're going to remove any trace of
>> it from CPAN so it looks like it never exist
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Monday 15 October 2007 18:00:
>
>>> We're not going to retroactively remove it from the 2.x series. 3.0
>>> and beyond will not have straps.
>> To clarify further, upgrading from TH 2 to TH 3 will not
Geoffrey Young wrote:
>> Honestly, just convert to TAP::Parser. Straps has no future.
>
> Apache-Test subclasses Straps to override _command_line() and provide
> php as the test caller (so you can run t/foo.php with php instead of perl).
>
> unfortunately for us, the magic required for this to w
chromatic wrote:
> On Tuesday 16 October 2007 05:18:40 Michael G Schwern wrote:
>
>> Honestly, just convert to TAP::Parser. Straps has no future.
>
> It has a zombie future. You can't remove it for TEN YEARS because it's in
> the
> core and people with gove
Andy Armstrong wrote:
> On 16 Oct 2007, at 20:04, Michael G Schwern wrote:
>> If somebody REALLY cares they can gut it to use TAP::Parser so it gets
>> future
>> bug and feature fixes. But that's like putting rocket engines on a
>> blimp.
>
> To be honest w
Hi, you're getting this mail because your CPAN distribution makes use of
Test::Harness::Straps (or you're subscribed to perl-qa).
Test::Harness version 3 will not include Test::Harness::Straps. It was an
experiment, it didn't work out. Sorry. Current users of Straps are
encouraged to instead us
Eric Wilhelm wrote:
> /usr/local/sbin/mbBuild is:
>
> #!/bin/sh
> ./Build $@
^^
That should be "$@" or else it will get confused by spaces.
On a related note, that sort of thing is generally useful for those of us who
find typing ./Build just a little more annoying than "make".
demerphq wrote:
> On 10/19/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
>> * demerphq <[EMAIL PROTECTED]> [2007-10-19 18:50]:
>>> How does one use this then? Where is it documented?
>> http://module-build.sourceforge.net/META-spec-blead.html#configure_requires
>
> So how do i use this with MakeMake
chromatic wrote:
>> This is a specific sort of failure, and as far as I'm concerned it is an
>> improperly configured machine. I'm not going to include a redundant
>> Makefile.PL just to support people who don't upgrade their tools. It's
>> no different than not supporting perl 5.005.
I believe
nadim khemir wrote:
> I spend a rather large amount of time writing and running tests. There are a
> few things that could be better. I either don't know how or it may not
> possible. I thought we could share some of questions and ideas that can make
> working with tests more pleasent. This sho
This is an announcement that my modules will no longer try to be backwards
compatible with 5.5.x. This includes ExtUtils::MakeMaker and Test::More.
Toolchain modules will now target 5.6.0. Modules not part of the build
toolchain will be moving up to 5.8.0.
This doesn't mean I'm going to go right
brian d foy wrote:
> Fair enough. Can you make a list of the last versions of all of those
> that should work with Perl5.005? I suppose that's the current list
> right now.
Pretty much. If anyone wants to put in the effort to make such a list they
can, knock yourself out.
--
...they shared one
Gabor Szabo wrote:
> I would suggest for those who are really interested in OPS (Old Perl Support)
> to run the tests of the module(s) on OP and report them to CPAN Testers.
> That way we'll be able to fetch the
> "latest version passing its test on OP" for every module on any specific OP
> right f
Slaven Rezic wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
>> Why make this change now? I've always been frustrated at being hamstrung
>> from
>> using "new" features of perl. The Perl Survey results is what pushed me over
>> the edge. [
Andy Armstrong wrote:
> I've added logic that produces output like this:
>
> 13:54] andy $ prove t/sample-tests/skipall t/sample-tests/
> skipall_nomsg t/sample-tests/simple
> t/sample-tests/skipall..skipped: rope
> t/sample-tests/skipall_nomsgskipped: (no reason given)
> t/sample-tes
Matisse Enzer wrote:
> I am looking for a way to run a fully-automated CPAN build (using
> CPAN::Shell) of a local Perl module and its dependencies, but, I need to
> make REMOVE some directories from the compiled-in @INC during the build
> process.
While it is not documented, you can override what
chromatic wrote:
> I've just uploaded a new development version of UNIVERSAL::isa to the CPAN
> (1.00_00).
Got a link which search.cpan catches up?
--
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <[EMAIL PROTECTE
As interesting / important as all this might be or might not be, it has
nothing to do with quality assurance. Take it elsewhere. Perhaps Groklaw,
they might actually have some legal knowledge.
And please don't replace the argument with an argument about how this is
somehow related to QA.
David
Andy Armstrong wrote:
> It is done :)
>
> http://hexten.net/tapx/r867/Test-Harness-3.04.tar.gz
>
> or
>
> svn co http://svn.hexten.net/tapx/trunk
>
> =head2 Arguments to Tests
>
> It is possible to supply arguments to tests. To do so separate them from
> prove's own arguments with '--'. Fo
Andy Armstrong wrote:
> On 29 Nov 2007, at 02:17, Michael G Schwern wrote:
>> Why isn't this just:
>>
>> prove -v t/mytest.t --test_args='--url http://example.com'
>>
>> It's clear, it's unambiguous, it allows -- to mean what it&
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Wednesday 28 November 2007 20:11:
>
>> There's the additional problem that it restricts the test arguments to
>> only be allowed at the end of the prove command line. This means
>> switch ordering is import
Andy Armstrong wrote:
> Will the sky fall and babies cry if we go with '--'? I would hope not.
It closes off the conventional method of passing in files that look like
switches. So yes, that hunk of sky will fall.
> Let's have a quick show of hands and move on, eh?
>
> [ ] --
> [X] something e
Andy Armstrong wrote:
> I'd like
>
> # Run all tests
> $ prove --state=save -rb t/*.t
>
> # Re-run failures from above
> $ prove --state=fail -rbv
>
> # Re-run failures and remember failures
> $ prove --state=save,fail -rbv
>
> Using the third form repeatedly would run only the test programs th
Andy Armstrong wrote:
> Why so verbose?
>
> Aristotle's '::' suggestion is my favourite. It's syntactically clean.
> It's visually distinct from other switches - so you can easily see that
> something special is happing. It's short.
And without context it's totally void of meaning. Someone hit it
chromatic, I think, in that big prove argument, pointed out that Test::More
side-stepped the whole "shove all functionality into one interface" problem by
creating Test::Builder. TAP::Parser and prove should go in the same direction.
Over and above simply being a way to build new test libraries,
Looking at the tickets for Test::More I see it's mostly down to wishlist items
and unimportant things.
http://rt.cpan.org/Public/Dist/Display.html?Name=Test-Simple
I can identify only two real important bugs, as far as I'm concerned. The
first has to do with overloading. cmp_ok() doesn't DTRT wi
Andy Armstrong wrote:
> On 30 Nov 2007, at 01:32, Michael G Schwern wrote:
>> The absurdity of :: becomes more clear because you can apply the same
>> arguments to any switch of prove. Let's use ++ instead of '--color'
>> because
>> its syntactical
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-11-30 02:35]:
>> Let's use ++ instead of '--color' because its syntactically
>> clean and visually distinct. Or ;; for --merge.
>
> Except there’s no good precedent for sentinel value
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Thursday 29 November 2007 19:00:
>
>> Otherwise, what's important to people?
>
> Could it be made fork-safe?
>
> http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
>
> Possibly that involve
Andy Armstrong wrote:
> On 30 Nov 2007, at 03:00, Michael G Schwern wrote:
>> Otherwise, what's important to people? I know there's a lot of
>> suggestions
>> about increasing the flexibility of planning. Also the oft requested
>> "I'm
>> done
As threatened, here's Test::Fork for easier writing of forked tests.
http://pobox.com/~schwern/src/Test-Fork-0.01_01.tar.gz
use Test::More tests => 4;
use Test::Fork;
fork_ok(2, sub{
pass("Child");
pass("Child again");
});
Michael G Schwern wrote:
> Otherwise, what's important to people?
Here's something that's important to me. I'd like to make it easier for
people to patch my modules. A bunch of people already have write access to my
repository, and I've taken care to ensure that mo
Fergal Daly wrote:
> One of the supposed benefits of using TODO is that you will notice
> when the external module has been fixed. That's reasonable but I don't
> see a need to inflict the confusion of unexpectedly passing tests on
> all your users to achieve this.
Maybe we should just change the
Fergal Daly wrote:
>> As long as you're releasing a new version, why would you not upgrade your
>> module's dependency to use the version that works?
>
> Your module either is or isn't usable with version X of Foo.
>
> If it is usable then you would not change your dependency before or
> after the
Chris Dolan wrote:
> On Dec 2, 2007, at 1:34 PM, nadim khemir wrote:
>> Because a TODO means that it is not done not: it might happend to be
>> done but
>> I'm not really sure, maybe I get lucky.
>>
>> Either one removes the TODO and all is fine. Or it might just be a
>> side effect
>> that you ha
So I read two primary statements here.
1) Anything unexpected is suspicious. This includes unexpected success.
2) Anything unexpected should be reported back to the author.
The first is controversial, and leads to the conclusion that TODO passes
should fail.
The second is not controversial,
use Test::More;
pass();
plan tests => 2;
pass();
Why shouldn't this work? Currently you get a "You tried to run a test without
a plan" error, but what is it really protecting the test author from?
Historically, there was a clear technical reason. It used to be th
David Golden wrote:
> Michael G Schwern <[EMAIL PROTECTED]> wrote:
>> It also makes it technically possible to allow the test to change it's plan
>> mid-stream, though the consequences and interface for that do require some
>> thought.
>
> With some sugar,
Eric Wilhelm wrote:
> # from David Golden
> # on Monday 03 December 2007 19:55:
>
>> With some sugar, that could actually be quite handy for something like
>> test blocks. E.g.:
>>
>> {
>> plan add => 2;
>> ok( 1, "wibble" );
>> ok(1, "wobble" );
>> }
>
> or maybe make the block a sub
>
>
A. Pagaltzis wrote:
> Yes, so this should be allowed:
>
> pass();
> plan 'no_plan';
> pass();
>
> Whereas this should not:
>
> pass();
> plan tests => 2;
> pass();
Umm, why not? That's exactly what I was proposing and it would result in...
ok 1
ok 2
Smylers wrote:
>>> It also makes it technically possible to allow the test to change
>>> it's plan mid-stream
>> Without some hypothetical future version of TAP this is only possible
>> if you have run tests before declaring a plan at all, because
>> otherwise the plan will already have been output
A. Pagaltzis wrote:
> That would work. Of course once you have that, you don’t need to
> allow assertions to run without a plan, since one can always say
>
> use Test::More tests => variable => 0;
> pass();
> plan add_tests => 2;
> pass();
>
> instead of
>
> use Test::More;
>
Geoffrey Young wrote:
>
> Andy Armstrong wrote:
>> On 4 Dec 2007, at 15:22, Geoffrey Young wrote:
>>> it would be nice if this were enforced on the TAP-digestion side and not
>>> from the TAP-emitter side - the coupling of TAP rules within the
>>> TAP-emitter is what lead to my trouble in the firs
Andreas J. Koenig wrote:
> Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm?
>
> http://www.nntp.perl.org/group/perl.cpan.testers/796974
> http://www.nntp.perl.org/group/perl.cpan.testers/825449
>
> All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter
> concludes UNKNO
This this whole discussion has unhinged a bit from reality, maybe you can give
some concrete examples of the problems you're talking about? You obviously
have some specific breakdowns in mind.
Fergal Daly wrote:
>> Modules do not have a binary state of working or not working. They're
>> compose
Geoffrey Young wrote:
> I guess what I thought you were getting at was a natural decoupling of
> comparison functions with the planning without all the hackery involved
> to get that sepraration working now. so I was suggesting that the
> decoupling go further than just no_plan, and that yeah, roc
Eric Wilhelm wrote:
>> A. Pagaltzis wrote:
>>> ...
>>> which would still be an error. That way a mistake in a test
>>> script won’t lead to Test::More silently converting an up-front
>>> plan declarations into trailing ones.
>> Which brings us back to the original question: why should that be an
>
7;s desires.
* TAP::Harness (aka Test::Harness 3) has fairly easy ways to control how
TODO tests are interpreted.
** It could be made easier, especially WRT controlling "make test"
** CPAN::Reporter could be made aware of TODO passes.
Fergal Daly wrote:
> On 05/12/2007, Mi
Eric Wilhelm wrote:
> Since we're on the subject of CPAN::Reporter, TAP::Harness, Test::More,
> and TODO wrt failure vs. no-noise vs. report-back vs. await-dependency
> and the binaryism of failure and etc...
>
> Perhaps a general sort of MAYBE namespace in TAP would be a nice
> addition.
Is t
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 04:30]:
>> Why do they care if the plan is output at the beginning or end?
>> How does this stricture improve the quality of the test?
>
> It improves the resulting TAP stream, if not the tes
Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Wednesday 05 December 2007 05:47:
>
>>> Perhaps a general sort of MAYBE namespace in TAP would be a nice
>>> addition.
>> Is this a joke? I hope it's a joke.
>
> Do I look like I'm joking? &
Eric Wilhelm wrote:
>> Give me something concrete, not just "it's better". I'm going to
>> keep drilling through the BS until I either hit bottom or punch
>> through.
>
> It allows you to apply the policy "all tests have a plan" at the test
> level. Yes, policy often sounds like BS.
>
> By his
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]:
>> I'm going to keep drilling through the BS until I either hit
>> bottom or punch through.
>
> Yeah, we’re all spouting bullshit. Gee, some tone you’re setting.
Sorry, I forgot the
Fergal Daly wrote:
> The importance of the test has not changed. Only the worth of the
> failure report has changed.
>
> This could be solved by having another classification of test, the
> "not my fault" test used as follows
>
> BLAME: {
> $foo_broken = test_Foo(); # might just be a version ch
Ok, here's what I've decided about the changes to the way Test::Builder
handles plans. None of this requires TAP or Test::Harness changes.
* The restriction on requiring a plan before running a test will be lifted.
use Test::More;
pass();
plan tests => 2;
pass()
Ovid wrote:
>> Side note: those features I really want control over in
>> Test::Harness
>> are the plan() and ok() methods. There's no clean way for me to do
>> that. Just look at the constructor:
>>
>> my $Test = Test::Builder->new;
>> sub new {
>> my($class) = shift;
>> $Test |
Ovid wrote:
> Test results currently look something like this:
>
> t/foo.t. ok
> t/bar.t. ok
> t/baz.t. 23/?
> # Failed test at t/baz.t line 9
> # Looks like you failed 2 tests out of 23
> t/baz.t. Dubious, test ...
>
>
Test::More's tests of its recursive testing functions (is_deeply() and the
eq_* functions) with threads has had an annoying intermittent failure for a
while. I've never been able to reproduce it because in the past it has only
occurred on machine types I don't have access to. But I noticed a CPAN
Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a
test which checks your signature doesn't appear to be an actual deterrent to
tampering. The man-in-the-middle can just delete the test, or just the
SIGNATURE file since it's not required. So why ship a signature test?
The
Adrian Howard wrote:
>
> On 11 Dec 2007, at 05:12, Michael G Schwern wrote:
>
>> Adam Kennedy posed me a stumper on #toolchain tonight. In short,
>> having a
>> test which checks your signature doesn't appear to be an actual
>> deterrent to
>> tampe
Andreas J. Koenig wrote:
>>>>>> On Mon, 10 Dec 2007 21:12:51 -0800, Michael G Schwern <[EMAIL
>>>>>> PROTECTED]> said:
>
> > Adam Kennedy posed me a stumper on #toolchain tonight. In short, having a
> > test which checks your
Edwardson, Tony wrote:
> Anyone written any CPAN modules for which the testing coverage needs to be
> improved ?
>
> Want someone else to sort this out for you ?
...
> Any takers ?
http://search.cpan.org/dist/ExtUtils-MakeMaker
Repository here:
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMake
Andreas J. Koenig wrote:
>>>>>> On Fri, 14 Dec 2007 15:49:32 -0800, Michael G Schwern <[EMAIL
>>>>>> PROTECTED]> said:
> > We would seem to be agreeing. If the goal of the test suite is not to
> protect
> > against spoo
Andreas J. Koenig wrote:
>>>>>> On Sat, 15 Dec 2007 01:34:37 -0800, Michael G Schwern <[EMAIL
>>>>>> PROTECTED]> said:
>
> >> See above. Once the bug is reported there is no justification to keep
> >> the test around. In
nadim khemir wrote:
> On Saturday 15 December 2007 20.53.30 Michael Peters wrote:
>> The uploaded file
>>
>> TAP-Harness-Archive-0.03.tar.gz
>> ...
>
> Nice. Now, what do we do with it?
You RTFM.
http://search.cpan.org/perldoc/TAP::Harness::Archive
--
If at first you don't succeed--you fa
1301 - 1400 of 1671 matches
Mail list logo
