Hi Karen,
On 13 Jul 2014, at 16:56, Karen Etheridge wrote:
>
> You can also reach a wider audience by granting comaint or first-come
> privileges to one of ADOPTME, HANDOFF, or NEEDHELP, which allows the PAUSE
> admins to grant permissions immediately when someone willing comes along:
[snip]
A
So — nobody then ;-)
Adrian
On 27 Jun 2014, at 09:58, Adrian Howard wrote:
> To join Fergal’s request for module adoption…
>
> My spare tuits are being spent in other places than perl development at the
> moment — and the ticket queue for my modules is building up a bit.
>
To join Fergal’s request for module adoption…
My spare tuits are being spent in other places than perl development at the
moment — and the ticket queue for my modules is building up a bit.
If anybody is willing to take 'em over please drop me a line.
Test::Class & Test::Exception are used a fa
On 31 October 2013 14:59, Ricardo Signes wrote:
>
> Once Test::Simple 1.001002 is release, I will upload Test-Class 0.40, which
> makes it pass its tests with 0.98 and previous as well as 1.001001 and later.
[snip]
And a big thank you from LazyAdrian™ for Ricardo sorting this out for him ;-)
Adr
On 27 April 2013 15:19, Ricardo Signes wrote:
> Test::Exception fails, which breaks a lot of my basic toolchain from
> installing.
T::E 0.32 just uploaded that kills the false failure.
Adrian
--
http://quietstars.com adri...@quietstars.com twitter.com/adrianh
t. +44 (0)7752 419080 s
On 21 March 2013 22:35, Michael G. Schwern wrote:
> Sorry you can't make it Curtis. It won't be the same without you. :-/
>
> Come to think of it, it might be a whole lot quieter if we're not
> fighting like a married couple. ;)
We need the antithesis of rubber-duck debugging. Some kind of stuff
Bugger. Clashes with a previous commitment. Sad face :-(
Hiya,
On 30 Oct 2011, at 19:23, Michael G Schwern wrote:
[snip]
>> * How would a no_plan subtest merge into a planned stream?
>
> Just fine, thanks. It would require no work at all. Without the TAP
> formatting, a no_plan subtest is equivalent to just running some tests.
What I was thinking of
Hiya,
On 29 Oct 2011, at 10:20, Michael G Schwern wrote:
> On 2011.10.29 1:51 AM, Adrian Howard wrote:
>> On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
>> [snip]
>>> Do you find *blocks with their own name and plan* convenient, or subtests
>>> which have
Hey,
On 29 Oct 2011, at 09:18, Michael G Schwern wrote:
[snip]
> Do you find *blocks with their own name and plan* convenient, or subtests
> which have their own separate test state (as currently implemented)
This may be me being dim - but I'm not really groking the distinction you're
making. C
On 23 Jan 2011, at 01:36, Ricardo Signes wrote:
> * Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 [2011-01-21T15:40:37]
>> this year's prospective date for the QA hackathon in Amsterdam is 16-18
>> April.
>> Please reply until Monday morning European time whether this is suitable for
>> you, or you would rather have a dif
On 13 Aug 2009, at 02:27, Michael G Schwern wrote:
Also Test::Class' tests are
broken with the latest release of Test::Builder. Does Adrian know
that?
Yes I do. Been to idle/busy to fix. Mostly the later. Apologies to
those affected.
Should really get the damn thing on github and spre
On 7 Jul 2009, at 15:47, Erik Osheim wrote:
On Tue, Jul 07, 2009 at 10:10:19AM +0200, Steffen Schwigon wrote:
Maybe it's not the latest version you attached, I think it's only the
skeleton from module::starter.
Well, I suppose it's better that I sent the wrong tarball here, rather
than uploa
On 29 Mar 2009, at 17:34, Yanick Champoux wrote:
Ovid wrote:
Just to let folks know, at the Perl-QA Hackathon, I've implemented
nested TAP in Test::Builder.
Ooooh This calls for a spontaneous dance of joy!
A few months ago, I hacked Test::Class so that it uses Test::Group
to
On 26 Mar 2009, at 18:39, chromatic wrote:
On Thursday 26 March 2009 11:27:13 Michael G Schwern wrote:
If I was to come up with a good argument as to why not to run the
tests in
production that would be it. The possibility of screwing up the
production
data is too great.
That's the onl
On 16 Mar 2009, at 18:47, Michael G Schwern wrote:
Adrian Howard wrote:
On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
[snip]
The test numbering exists to ensure that all your tests run, and in
the right
order. XUnit frameworks don't need to know the number of tests
because they
s
On 16 Mar 2009, at 18:23, Fergal Daly wrote:
[snip]
Really? I know of at least one automated test runner (by this I mean
it runs all the test files it can find) for pyunit that would say
"everything
is fine" if I through a random sys.exit(0) into my test script.
[snip]
That's why I said "most"
On 16 Mar 2009, at 23:52, Fergal Daly wrote:
2009/3/16 Michael G Schwern :
[snip]
I hear where you're coming from, but there is some value in knowing
a test
still does what it did before. A regression test.
Consider the following:
my @things = $obj->things(3);
for my $thing (@thing
On 14 Mar 2009, at 05:57, Michael G Schwern wrote:
[snip]
The test numbering exists to ensure that all your tests run, and in
the right
order. XUnit frameworks don't need to know the number of tests
because they
simply don't have this type of protection. [1]
[snip]
And, to some extent, ne
On 17 Apr 2008, at 06:48, Chris Dolan wrote:
[snip]
Interesting reactions:
* People were appalled that Test::Class invokes methods in
alphabetic order instead of lexical order
If it's any comfort so is the author :-) At some point I'll be
changing T::C to follow lexical-order-by-class met
Hi Folks,
I *am* going to Oslo - despite my complete silence on the topic. Been
stupidly busy on tedious things for the last few weeks. I'm due in to
the airport at 8:40 so I'm probably just going to go to the hotel
(Anker) and crash.
Looking forward to seeing y'all there Saturday morning
On 26 Feb 2008, at 08:53, Cosimo Streppone wrote:
Hi all,
I'm using Test::Class and I'm happy with it.
I wrote several test classes which inherit from T::C,
but I wanted to avoid the "1-*.t-script-for-each-test-class"
approach.
[snip]
You mean like Test::Class::Load
http://search.cpan.org/d
On 13 Feb 2008, at 00:10, Michael G Schwern wrote:
[snip]
Data::Dump::Streamer can decompile a code reference, complete with
attached lexicals. But as has been pointed out by Yuval, the real
trick is to show the value of all variables used in the block.
[snip]
Yeah... hadn't considered glo
On 12 Feb 2008, at 04:52, Andy Lester wrote:
Some interesting ideas for how the Ruby folks are now doing their
unit testing.
http://www.oreillynet.com/ruby/blog/2008/02/assert2.html
By "the Ruby Folks" you mean "Phlip" I think - not seen a mad
adoption of it yet :-)
Been considering do
On 27 Jan 2008, at 00:40, Ian Malpass wrote:
I'm writing Test::Pod::URI, which is going to follow pretty much
the same structure as Test::Pod::Coverage. As such, I've got a
subroutine all_pod_uris_ok() which will find all the POD files in a
distro and test them using the pod_uris_ok() subr
On 15 Jan 2008, at 11:18, Ovid wrote:
[snip]
* Make it subclassable.
* Allowed deferred plans.
* Allow for TAP upgrades (YAMLish, YAMLish, YAMLish!).
* "On Fail" callbacks? (I realize lots of people will squawk here)
* [insert your desired features here]
Don't get hung up on the "On
On 7 Jan 2008, at 16:29, Nicholas Clark wrote:
On Mon, Jan 07, 2008 at 03:59:18PM +, Adrian Howard wrote:
Actually, I've had some nasty bugs in the past with prints failing
with dodgy NFS mounts. Caused some important data to go away. Not my
code fortunately :-)
In these circumst
On 6 Jan 2008, at 11:10, Michael G Schwern wrote:
[snip]
But it gets down even further. All tests are not equal. Good
tests are not
about making perlcritic happy or achieving 100% test coverage or
satisfying
some conviction about testing first.
[snip]
Absolute 100% agreement from me. I'v
On 2 Jan 2008, at 20:02, nadim khemir wrote:
On Saturday 29 December 2007 10.11.41 Matisse Enzer wrote:
I've spent some of this holiday season learning how to set up
BuildBot
...
Cabie seems to be as good, if not better (psst, it's written in Perl).
http://cabie.tigris.org/
There's also
On 2 Jan 2008, at 23:45, chromatic wrote:
On Wednesday 02 January 2008 08:55:40 Adrian Howard wrote:
* Pointless warnings from UNIVERSAL::can needed to be stomped.
Is this with U::c 1.13_001?
Nope. 1.12.
Adrian
On 29 Dec 2007, at 23:31, Ovid wrote:
Hi all,
I've just released a new version of Test::Aggregate
(http://search.cpan.org/dist/Test-Aggregate/).
[snip]
A quick experience report.
After about three hours work I shifted all of the tests that worked
without changes in a $work project to use T
On 1 Jan 2008, at 18:47, Eric Wilhelm wrote:
# from Ovid
# on Tuesday 01 January 2008 00:12:
[snip]
This is the sort of stuff that tests are designed to catch, but stuff
this bad *might* get missed with tight process boundaries.
...
(such as the time someone was parsing
Data::Dumper output wi
On 31 Dec 2007, at 23:07, Eric Wilhelm wrote:
# from Adrian Howard
# on Monday 31 December 2007 11:18:
That's been my experience too. I've caught many nice bugs that would
have been missed by completely-clean slate tests.
Are they bugs in the tests or actual bugs?
Both. More
On 31 Dec 2007, at 11:15, Ovid wrote:
--- Eric Wilhelm <[EMAIL PROTECTED]> wrote:
Now, assuming that both ways carry the same caveats, I too would
prefer
the latter because it not only eliminates load time, but also allows
concurrency and provides isolation via the boundary between child
proc
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
tampering. The man-in-the-middle can just delete the test, or just
the
SIGNATURE file
On 5 Dec 2007, at 12:13, A. Pagaltzis wrote:
* Adrian Howard <[EMAIL PROTECTED]> [2007-12-05 10:45]:
There are design mistakes that I regret. Only some of them can
be fixed without breaking backwards compatibility.
Maybe time to put Test::Class on ice and fork an incompatible
suc
On 4 Dec 2007, at 06:52, Michael G Schwern wrote:
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
On 5 Dec 2007, at 01:24, Chris Dolan wrote:
[snip]
Are you proposing that Test::Class go in core? I second the
motion! :-)
I'm not! It shouldn't be there. There are design mistakes that I
regret. Only some of them can be fixed without breaking backwards
compatibility. Not something that
On 3 Dec 2007, at 04:34, Michael G Schwern wrote:
[snip]
This doesn't mean that people don't use dies_ok() when they should use
throws_ok(). Every tool is open to abuse. The solution is not to
remove the
tool, but figure out why it's being abused. Maybe the answer is as
simple as
putting
On 3 Dec 2007, at 10:26, A. Pagaltzis wrote:
* Ovid <[EMAIL PROTECTED]> [2007-12-02 16:50]:
Breaking the toolchain is bad.
You can almost imagine Curtis murmuring those words even in
his sleep…
I have lost count of the number of times Andy/Ovid said this over the
LPW weekend :-)
Adrian
On 29 Nov 2007, at 15:08, Andy Armstrong wrote:
[snip]
One I'd like even more would be to run tests in order of most-
recently-failed. It's something I've hacked together several times
at various companies with T::H::Straps.
$ prove --state=fail,all,save
?
(option order matters, 'fail' add
On 29 Nov 2007, at 14:56, 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 progr
On 29 Nov 2007, at 12:20, Andy Armstrong wrote:
[X] --
[ ] something else (please specify)
Adrian
On 19 Nov 2007, at 23:04, A. Pagaltzis wrote:
[snip]
A deferred plan is clearly not as good as a predeclared plan,
but is definitely much safer than no plan at all.
[snip]
I don't get this. Why is saying "I know this test script outputs 8
test results" at the start better than saying it at t
On 19 Nov 2007, at 23:08, Andy Lester wrote:
On Nov 19, 2007, at 5:04 PM, A. Pagaltzis wrote:
A deferred plan is clearly not as good as a predeclared plan,
but is definitely much safer than no plan at all.
But what if something blows up before getting to the deferred
plan? Then you don
On 19 Nov 2007, at 11:04, Ovid wrote:
[snip]
That avoids the overhead of reloading perl and the modules multiple
times. However, each .yml file defines its own test count and I
don't want 'no_plan'. What I really want to do is this:
use Test::More 'deferred_plan'
my $plan = 0;
fore
On 18 Nov 2007, at 11:50, nadim khemir wrote:
Hi, This mail is not discussing what quality and what test quality
is. It is
about what quality our 'test files' have.
I run Test::Fixme, Kwalitee, perl::Critic, etc ... on my modules
but none of
them is ran on my tests. tests have a tendency
On 12 Nov 2007, at 17:43, Eric Wilhelm wrote:
[snip]
Perhaps a solution which involves a pre-fork model of
Test::Class would be a little neater. The "test scripts"
would then be sub-sub-processes and the harness just needs
filehandles from each of those.
[snip]
Yeah - that would be ne
On 13 Nov 2007, at 04:29, Geoffrey Young wrote:
The metric will be called prereq_matches_use and shall check if
all the
modules used in a dist are also listed as a prereq.
I find this odd.
if I check a prereq for mod_perl (.pm) I know I have the 50 some
modules
that come with a mod_per
On 26 Oct 2007, at 18:05, Eric Wilhelm wrote:
# from Jonathan Swartz
# on Friday 26 October 2007 06:53:
I'd like to avoid actually running a single script per class, for
efficiency reasons - i.e. I agree with Ovid and Adrian here:
http://use.perl.org/~Ovid/journal/31172
It seems like it
On 3 Oct 2007, at 15:27, Ovid wrote:
I'm thinking about writing Test::Load (similar to Test::Class::Load).
It would be a wrapper around http://use.perl.org/~Ovid/journal/34596.
Basically, you'd do something like this in t/00-load.t (or whatever
you
call it):
use Test::Load
lib
On 17 Sep 2007, at 12:49, A. Pagaltzis wrote:
* Jonathan Rockway <[EMAIL PROTECTED]> [2007-09-17 13:20]:
Your method was much better than my "try installing stuff I
need and see what fails" technique :)
If anyone has a CPAN grepper script they could do an even better
job with less effort tha
On 1 Sep 2007, at 18:36, Ovid wrote:
[snip]
How about something more direct: harness_supports_tap_diagnostics();
I thought about something more verbose, but I confess that I like to
avoid longer function names. They irritate people. Still, maybe it's
worth it in this case.
[snip]
++ for l
On 28 Aug 2007, at 11:26, Ovid wrote:
[snip]
If we can't come to a consensus, I'll plow ahead regardless.
Go plough my friend :-)
As usual,
this means I might create something that no one likes. What I'd
prefer
to define is the *minimum* required keys in the YAML diagnostics and
perhap
On 2 Aug 2007, at 19:05, nadim khemir wrote:
[snip]
Test::Block
[snip]
I (personally) don't think T::B is generally useful enough. These
days I'd push things like Test::Group / Test::Class instead.
Cheers,
Adrian
On 31 Jul 2007, at 12:24, Andy Armstrong wrote:
On 31 Jul 2007, at 12:16, Michael G Schwern wrote:
I was about to say that. I declare LWP as a prereq, but loading
LWP loads
tons more modules. I don't have to declare all those as prereqs,
in fact I
should not as its violating LWP's encaps
On 31 Jul 2007, at 11:56, Ovid wrote:
[snip]
We can see right away from the report above that Test::Class will
cause
many folk's installs to fail since it's not listed as a prereq and
it's
possible that SUPER doesn't need as high a version as is listed,
though
investigation into the histor
On 3 Jul 2007, at 08:57, Ovid wrote:
- Original Message
From: Adrian Howard <[EMAIL PROTECTED]>
As you can see, I called SUPER::startup instead of SUPER::setup.
[snip]
Not that it helps solve your problem - but I tend to use multiple
setup routines rather than inheritance
Belated response...
On 1 Jul 2007, at 23:19, Ovid wrote:
[snip]
I've just spent quite a bit of time debugging a problem where a
Test::Class setup method was misbehaving. My tests passed, but
mysql was spitting out errors directly to STDERR and quite a bit of
tracing led me to the following
On 20 Jun 2007, at 09:35, Ovid wrote:
[snip]
Planning out a "dream" API is a wonderful and powerful thing and
when done correctly, it can be useful. Thus, writing POD first
*might* be a good idea. However, I do agree with Shlomi on this.
I have grown to appreciate the ability to evolve m
On 8 Jun 2007, at 13:04, Andy Armstrong wrote:
[snip]
I can see the benefits of keeping a method and its documentation
adjacent. Intuition would would pull me in that direction - but
practice pulls me in the other direction. When I have my
documentation head on I just want to see documentat
On 8 Jun 2007, at 01:14, Joshua ben Jore wrote:
On 6/7/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
I've never seen the benefit of pod after __END__. IMO, your code and
docs should follow the same order/groupings. That, and you have to
It has two benefits. Separating code from pod prevents
On 23 May 2007, at 19:53, Nadim Khemir wrote:
Hi, I just uploaded POD-Tested to CPAN (It may take a few hours
before it is
accessible). it's a fun little module to write cookbooks. It lets
you test
the content of you cookbook and generate some sections dynamically.
[snip]
You might want t
On 24 Apr 2007, at 13:58, Adriano Ferreira wrote:
[snip]
I was trying to come up with a fix for Test::Base which does not seems
to interact well with other test modules. In the current sources, it
has its own $Have_Plan variable. Then I tried to replace this with
$Test::Builder->new->has_plan.
Hiya,
On 29 Mar 2007, at 21:08, Ovid wrote:
[snip]
package My::Tests;
use Test::Custom qw(
Test::More
Test::Differences
Test::Exception
);
1;
Nice idea. Looking very like David Golden's ToolSet module, or
Damian's Toolkit. Could you extend one of those?
Adrian
On 29 Mar 2007, at 10:02, David Cantrell wrote:
Michael G Schwern wrote:
Its for the case where you're subclassing a class which does not
have a .pm
file.
"So don't do that then"
Why not - it's bloody useful?
Adrian
On 28 Mar 2007, at 01:46, Kirrily Robert wrote:
[snip]
Any suggestions for how to work around this? All I've got so far
is the
idea of splitting out the web tests into another directory, and
treating
them as "functional tests" that developers would typically run less
often than the unit tes
On 19 Mar 2007, at 12:51, Geoffrey Young wrote:
hi all...
it's really hard to wade through the flurry of activity of late,
but is
the consideration really to alter current TAP to make it look like
YAML?
Nope. It's to add some simple YAML-ish output in places to help
clarify things. It'
On 16 Mar 2007, at 07:53, Michael G Schwern wrote:
[snip]
I don't know if we need all 8 levels used in syslog. I'm not sure
where the
distinction comes between "Emergency", "Alert", "Critical" and
"Error" when it
comes to testing. But its a good start. Some undefined levels we
can defin
On 14 Mar 2007, at 16:04, Ricardo SIGNES wrote:
* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-09T18:17:57]
*) TAP diagnostic format
http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
There is no way to output diagnostics in TAP. The stuff
Test::More spits
out to STDERR are unparsabl
On 14 Mar 2007, at 11:54, Ovid wrote:
Rather than repeat the entire post here, there is a conceptual problem
with setup methods in Test::Class. I'm just not sure if the
conceptual
problem is mine or Test::Class's :)
http://www.perlmonks.org/?node_id=604787
Rather than repeat my entire re
On 8 Mar 2007, at 11:17, Ovid wrote:
[snip]
How do I run an individual test class which inherits from
"My::Test::Class" and have the INIT block in "My::Test::Class"
dynamically determine which test class name to put there? That's
what's stumping me.
[snip]
Damn. I knew that asymmetric treatme
On 8 Mar 2007, at 10:44, Ovid wrote:
[snip]
I cannot easily use 'Test::NoWarnings' because that adds an extra
test,
thus forcing me to use 'no_plan' with one of my tests. Is there some
other way around this?
[snip]
Do something like:
INIT { Test::Class->runtests( 'Foo', +1 ) }
Also, not
On 5 Mar 2007, at 22:30, Ovid wrote:
(Resent from the address I've actually subscribed from!)
Hi all,
Per an email from Schwern, he does not object to renaming TAPx::Parser
to TAP::Parser. Hence, we have an official 'blessing' from him for
claiming this namespace. Does anyone have any thoug
On 5 Mar 2007, at 13:38, Ovid wrote:
--- Eric Hacker <[EMAIL PROTECTED]> wrote:
Given all of this chat, what would folks think about an optional
switch
to 'runtests' (the TAPx::Parser equivalent to 'prove'), which would
warn users about which test programs are being run without a plan?
T
On 2 Mar 2007, at 22:53, James E Keenan wrote:
Adrian Howard wrote:
[snip]
Adrian: How about posting this part on http://perl-qa.yi.org/
index.php/Main_Page?
[snip]
ObItsAWiki :-)
Adrian
On 4 Mar 2007, at 03:40, Matisse Enzer wrote:
A tangential comment:
The xUnit approach avoids this question of "counting" altogether -
you create one or more subroutines whose names begin with 'test',
each of which contain one or more assertions such as is_deeply($got,
$expected); and th
On 1 Mar 2007, at 16:42, Andrew Gianni wrote:
[snip]
In this situation, we would still like something in place to ensure
that
altering the construction of the business rules doesn't cause
regression in
the application, but we can't (or I'd certainly rather not) simply
write
unit tests for. I
On 2 Mar 2007, at 00:35, Adam Kennedy wrote:
[snip]
Well, except you aren't supposed to do that, because if ->isa can
be overloaded, it can also die or throw an exception. So eval
{ $obj->isa($class) } falsely ignores errors.
[snip]
That, of course, depends on whether you want to ignore err
On 26 Feb 2007, at 18:23, chromatic wrote:
[snip]
I'm open to a patch that allows people who know what they're doing
to disable
the warnings.
Thank you!
Adrian said he might write one.
[snip]
I shall. I might even do it now :)
Adrian
On 15 Feb 2007, at 12:35, David Cantrell wrote:
[snip]
The version of Test::Simple distributed with perl 5.6.2, which is
presumably being used by one of your dependencies, is 0.47, so one
result was testing with the earlier version, the other with the
current
version. There was an API change
On 13 Feb 2007, at 18:49, Eric Wilhelm wrote:
[snip]
How about, "a thing into which the item under test gets inserted"?
The
c2 wiki (http://c2.com/cgi/wiki?TestFixture) has it as analogous to an
electronics test fixture. They should probably include "light
fixture"
as a very simple metaph
Hiya,
On 13 Feb 2007, at 22:46, Kirrily Robert wrote:
Thanks all, especially Ovid who came closest to answering the actual
question, i.e. can someone explain it to me *in a perlish way*.
Ovid's
example used Test::Class's setup/teardown;
You saying that T::C isn't Perlish? Wanna make somet
On 3 Feb 2007, at 08:01, Joe McMahon wrote:
On Feb 2, 2007, at 2:03 AM, Ovid wrote:
[snip]
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 Test::Description::Tagged which I rea
Hi Dave,
On 2 Feb 2007, at 12:30, David Golden wrote:
[snip]
There is a different case that needs to be considered. Module Fribble
uses an eval in it's DESTROY method without error and thus Foo's fatal
error in an eval vanishes.
[snip]
Good point.
Because Perl normally warns but doesn't die
On 2 Feb 2007, at 07:23, Gabor Szabo wrote:
[snip]
Can I use TAP for this? Can TAP be used to represent such hierarchy?
Is there a module already doing something like this even without
the HTML
report?
[snip]
Currently there isn't any in built support for hierarchical test
reporting in TAP
On 1 Feb 2007, at 21:56, Nadim Khemir wrote:
On Thursday 01 February 2007 22:37, Joshua ben Jore wrote:
I'd be a happy guy if a paranoid T::E caused consternation and people
to post "OMG! My stuff fails now!" to perlmonks or whatever.
I use T::E extensively and I, too, would like to see a c
On 1 Feb 2007, at 21:37, Joshua ben Jore wrote:
[snip]
Ok, I'll give you that a user may want to ignore errors that occur
during scope cleanup but from the point of view of T::E, it seems
relatively clear that an error really has occurred.
I'd tend to think
that T::E's default behavior would be
On 1 Feb 2007, at 16:28, Joshua ben Jore wrote:
[snip]
There's is nothing special about what T::E is doing to detect errors -
it just turns out the popular practice of looking at $@ is flawed.
That's a problem with the pattern and I expect that what it means is
that if T::E starts detecting error
On 31 Jan 2007, at 16:42, Joshua ben Jore wrote:
[snip]
dies_ok { $o->annoying_corner_case } 'exception thrown';
do the SIG{__DIE__} dance make the tester write
dies_ok { $o->annoying_corner_case; 1 } 'exception thrown';
If the SIG{__DIE__} dance happens entirely in T::E (as I suggeste
On 30 Jan 2007, at 20:11, Joshua ben Jore wrote:
Interestingly, this has caused me to wonder how well Test::Exception
handles the corner cases where $@ is clobbered during the scope ending
of eval{} and related.
It doesn't. It's been on my list for some time, but I'm too lazy :-)
I've just
Hi Nadim,
On 30 Jan 2007, at 17:17, Nadim Khemir wrote:
[snip]
The bad guys:
# Check that something died
dies_ok { $foo->method1 } 'expecting to die';
Am I the only one who got this to pass, to find out later that what
cause the
error had nothing to do with the message I displayed.
[sn
On 30 Jan 2007, at 19:48, Eric Wilhelm wrote:
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
# all Test::Exceptions subroutines are guaranteed to preserve the
state # of $@ so you can do things like this after throws_ok and
dies_ok like $@, 'what the stringified exception should
On 30 Jan 2007, at 18:19, A. Pagaltzis wrote:
That could easily be accomodated by having `throws_ok` accept a
sub ref as its condition argument. Then Test::Exception could
pass the value of $@ to this sub as the first argument, and clear
$@ to force people to use that argument instead of $@ its
On 2 Jan 2007, at 11:07, Ovid wrote:
[snip]
I'm planning, within the next couple of weeks or so, to release a new
version of TAPx::Parser. Amongst other things, I have two test
harnesses now included with it (one is a subclass of the other which
allows test output to be colorized). Along with th
On 17 Dec 2006, at 20:46, Nadim Khemir wrote:
[snip]
The first problem I have is capturing the module output when it is
loaded.
I tried:
[snip]
You might want to look at Test::Output for this.
[snip]
I will also have a bunch of tests that need to be run under the
debugger.
[snip]
Why? (
On 30 Oct 2006, at 08:48, Jos Boumans wrote:
Greetings,
I got this bug report for CPANPLUS the other day, which turns out that
Test.pm
does not actually exit with a non-zero exitcode like Test::More
does on
failed tests:
http://rt.cpan.org/Ticket/Display.html?id=22685
This means neither
On 5 Oct 2006, at 15:11, Paul Beckingham wrote:
Recently I was required to create another flavor of test harness
that runs tests, then captures and stores output.
The nature of my testing means that I am running millions of tests,
and the resultant captured output is therefore huge. So I
On 28 Sep 2006, at 22:37, Jonathan Rockway wrote:
Override Test::Builder::ok to croak if it doesn't get a test name
argument. Package that up in a module and shim it in with PERL5OPT
or HARNESS_PERL_SWITCHES.
I kind of dislike this approach. If my tests are failing, I want them
to fail bec
On 27 Sep 2006, at 23:53, Christopher H. Laco wrote:
[snip]
Would it be possible, or even desirable to flip some sort of config to
make this test all t files, or tell this policy that my test class eq
'Test::More' in this instance?
[snip]
Not that this wouldn't be a nice idea, but as another a
1 - 100 of 278 matches
Mail list logo
