On 5 May 2005, at 18:00, David Wheeler wrote:
On May 5, 2005, at 04:26 , Adrian Howard wrote:
Here's a weird idea: how about the option of AJAXing the test
harness results back to a receiving server somewhere that
understands TAP? Bingo: TAP testing of JS embedded in web pages in
its n
On 23 May 2005, at 15:33, Ian Langworth wrote:
I'm working on a new module, Class::Agreement, and I've started by
writing the documentation. If anyone has a few minutes, I'd like some
feedback as to whether my descriptions of the concepts make sense and
if you like the syntax.
HTML: http://re
On 27 May 2005, at 16:21, Ian Langworth wrote:
[snip]
When you say "automatic," I think of source filtering. Do you simply
mean an alias for the first argument? If so, I think it's best to
leave that up to the programmer. You can always use shift.
Fair enough. I just hate having the duplicatio
On 27 May 2005, at 18:25, Ovid wrote:
--- Ian Langworth <[EMAIL PROTECTED]> wrote:
Reflecting upon this, I'm not even sure why I'd want argument
modification as a feature. (Maybe I still had Hook::LexWrap on the
brain.) I might just take this out.
I vote for taking it out. I view contract
On 31 May 2005, at 09:47, Adam Kennedy wrote:
[snip]
Something exist already that I'm missing?
[snip]
I'd use Test::Class (but I would say that :-) So the example from
your POD would be something like:
{ package Foo::Test;
use base qw( Test::Class );
use Test::More;
# w
On 30 May 2005, at 22:23, chromatic wrote:
[snip]
I'd love to have feedback before I release it to the CPAN in a week or
so.
[snip]
Getting some test failures on vanilla OS X 10.4.1 (see below). Not
got time to dig into causes at the moment.
Looks nice though. Like the roles stuff.
Adrian
On 2 Jun 2005, at 10:01, Michael G Schwern wrote:
[snip]
Test::More 0.48_02 introduced a change where it would put a leading
newline before its diagnostics when running under Test::Harness.
Looks
like the test expected that. You're probably running Test::More 0.47.
[snip]
Bah. I knew that
On 24 Jun 2005, at 06:27, David Wheeler wrote:
[snip]
See Test.Harness.Browser in action here:
http://www.justatheory.com/code/Test.Simple-0.10/tests/index.html
http://www.justatheory.com/code/Test.Simple-0.10/tests/index.html?
verbose=1
Sweet!
It probably says something quite sad about
On 8 Jul 2005, at 20:08, Adam Kennedy wrote:
[snip]
There's no way to get a listing of the annotations for a given
author id, or even for a given dist. So I'm reduced to manually
looking through a thousand odd web pages to find potential changes
or improvements to the code.
[snip]
htt
On 12 Jul 2005, at 22:00, Michael G Schwern wrote:
Barbie's journal, via Ovid, made me aware of patent EP1170667
"Software
Package Verification" granted last month in the EU.
http://gauss.ffii.org/PatentView/EP1170667
[snip]
Oh for f**k's sake :-(
Don't know any patent lawyers myself, but it
On 12 Jul 2005, at 23:07, Adrian Howard wrote:
[snip]
Don't know any patent lawyers myself, but it might be worth
dropping a line to one or more of:
http://www.nosoftwarepatents.com/en/m/about/contact.html
http://fsfeurope.org/
[snip]
http://www.eurolinux.org/ also might be
On 25 Jul 2005, at 22:29, Peter Kay wrote:
http://qa.perl.org/test-modules.html has a bunch of test modules
listed.
However, there are no harnesses listed. I know Test::Harness, and I'm
going to go read about Test::Builder, but what other "meta-testing"
modules are there?
[snip]
All depend
I've been pondering custom test runners recently and have hit the
familiar problem of Test::Harness::Straps not capturing STDERR, so
missing the diagnostics that Test::Builder outputs.
A moderately evil solution occurred, and I now have a
Test::Builder::STDOUT on my box that just does:
On 29 Jul 2005, at 11:31, Michael G Schwern wrote:
I've just implemented the oft requested Test::Builder::Module. Its a
superclass for all Test::Builder based modules that implements an
import()
method to match what Test::More does and a builder() method to get the
Test::Builder object.
N
On 29 Jul 2005, at 06:07, Michael G Schwern wrote:
BEGIN { *STDERR = *STDOUT }
That'll handle anything, Test::Builder or not.
Nope. T::H::S turns
analyse_file( 'foo.t' )
into something like
open(FILE, "/usr/bin/perl foo.t|" )
so the test script will get it STDERR disassociated from
On 29 Jul 2005, at 02:58, chromatic wrote:
If you can use your own test harness, use
Test::Harness::Straps::analyze() or
Test::Harness::Straps::analyze_fh()
to collect STDERR and STDOUT from the tested process.
Ah. That would make sense. Much more sensible. Off to play.
Adrian
Earlier today chromatic kindly gave me a gentle tap with the
cluestick which let me figure out how to give T::H::S STDERR &
STDOUT, which means my mates test results are now toddling off to a
SQLite database quite happily.
However, munging together my own command together with various
_pr
On 30 Jul 2005, at 00:00, Michael G Schwern wrote:
[snip]
Perhaps you misunderstand.
I did
I mean to put that BEGIN { *STDERR = *STDOUT }
in the test script. foo.t never prints to STDERR.
Doh. I would have to put in in a module so I could shim it in with
HARNESS_PERL_SWITCHES but yes,
On 30 Jul 2005, at 01:05, Andy Lester wrote:
On Fri, Jul 29, 2005 at 03:57:07PM -0700, Michael G Schwern
([EMAIL PROTECTED]) wrote:
This is, IMHO, the wrong place to do it. The test should not be
responsible
for decorating results, Test::Harness should be. It means you can
decorate
ANY te
On 30 Jul 2005, at 17:19, chromatic wrote:
(BTW chromatic: I'm curious why you didn't break todo tests into
separate passing/failing classes as you did the "normal" test?)
TAP doesn't, so I didn't see any reason to do it.
Well, I don't really see that TAP separates pass/fail todo tests any
On 15 Aug 2005, at 17:12, Yitzchak Scott-Thoennes wrote:
[snip]
The throw_ok { ... } syntax only works because the throw_ok sub exists
and has a prototype that specifies a subref is expected; if you don't
load Test::Exception by the time the throw_ok call is compiled, it
is parsed as an indirect
On 9 Sep 2005, at 21:55, David Golden wrote:
At least one of the culprits may be Test::Exception, for any
version before 0.20. The problem is that CPANPLUS doesn't
currently play well with Module::Build and doesn't respect the
"build_requires" parameter, but only looks at the "requires"
On 28 Dec 2005, at 16:36, Javier Amor Garcia wrote:
Hello,
i am testing a module for a web application and i need to test the
expiration of sessions. The problem is that i can not modify the
expiration time and i not want to make sleep the test for the full
length of expiration time (a hour)
On 9 Jan 2006, at 05:03, David Wheeler wrote:
[snip]
Is there any way to get Test::Builder to set an I/O layer on its
file handles?
[snip]
Y'want Test::Builder's failure_output(), e.g.:
use Test::More tests => 1;
binmode Test::More->builder->failure_output, ':utf8';
diag "\x{201c}";
ok 1;
C
Hi all,
On 2 Apr 2006, at 01:04, Jeffrey Thalhammer wrote:
I have never actually had an opportunity to practice
this, but I've always felt that the most obvious way
to combine test-driven development with pair
programming was to have one person write test code
while the other person writes appl
On 19 Apr 2006, at 09:02, Ovid wrote:
[snip]
From a parser standpoint, there's no clean way of distinguishing that
from what the test functions are going to output. As a result, I
really think that "diag" and normal test failure information should be
marked differently (instead of the /^# / tha
On 19 Apr 2006, at 17:12, Andrew Gianni wrote:
[snip]
We'd like to be a bit more programmatic about writing our mech
tests to test
use-case driven test-cases. I'm wondering if there are any tools or
ideas
out there to ease the process so we don't have to manually write the
numerous mech tests
On 20 Apr 2006, at 16:55, Michael Peters wrote:
[snip]
I'm not sure I agree that there is a difference between them. They are
both comments output by the tests. Just because one comes from the
testing routine used by the test and the other from the test itself
doesn't mean they aren't both just
On 23 Apr 2006, at 07:02, Andy Lester wrote:
[snip]
I've removed the meaningless percentages of tests that have
failed. If you rely on the output at the end, it's different now.
[snip]
I'll just repeat what I left on Andy's blog here in case anybody
agrees with me.
I don't like the
On 23 Apr 2006, at 20:05, Shlomi Fish wrote:
[snip]
This debate demonstrates why a plugin system is necessary for a
test harness.
If it has it, then one can write a plugin to control whether or not
percentages are displayed. So for example, you can install a plugin
that does
that, and put t
On 24 Apr 2006, at 15:51, Shlomi Fish wrote:
[snip]
Am I missing something or isn't that what
Test::Harness:Straps/Test::Run::Straps are for? If not, I suppose I
can
extract a class out of Test::Run::Straps that will provide a
reusable TAP
parser.
[snip]
In addition to Michael's and chroma
[apologies to andrew for a dupe - didn't notice it went to perl-qa]
On 31 May 2006, at 14:35, Andrew Gianni wrote:
Let me start by admitting that I don't know a whole lot about xUnit
testing.
In fact, using Test::Class is really my first exposure to the idea, so
perhaps I'm asking for somethi
On 1 Jul 2006, at 23:38, Michael G Schwern wrote:
Cons?
* Doesn't handle nested groups - but I have to admit that's a use
case I've never wanted :-)
* Doesn't handle groups with an undefined number of tests. The
obvious solution would be to allow ".." sans numeric suffix so you
would
On 1 Jul 2006, at 20:36, Michael G Schwern wrote:
[snip]
* How can I help?
Provide use cases, what would you want to do with Test::Harness if you
could? What are you doing with Straps? What features do other
testing systems (JUnit, for example) have that you'd like to see in
Perl? Once I pos
On 3 Jul 2006, at 13:56, Adam Kennedy wrote:
That seems like a problem too but the one I'm trying to get at is
4 no plan, with groups
If your script exits prematurely after one of the groups, the
harness
will not notice because everything looks just fine. The solution to
this is not to use
On 3 Jul 2006, at 17:47, Ovid wrote:
- Original Message
From: Michael G Schwern <[EMAIL PROTECTED]>
* Its backwards compatible. The ..# lines are currently considered
junk and ignored.
Is this behavior documented anywhere?
[snip]
From Test::Harness::TAP
Anything else
Any output
On 17 Jul 2006, at 12:49, Ovid wrote:
- Original Message
From: A. Pagaltzis <[EMAIL PROTECTED]>
[snip]
And you know what? We don’t even need Test::More::NextGen to
implement that. All functions as they stand could unambiguously
accept a hashref as their single argument.
That's goin
On 19 Jul 2006, at 08:18, Steffen Mueller wrote:
Andy Lester schrieb:
At this point, CPANTS rules are getting into the realm of purely
self-pleasuring. If more than a dozen people outside of this
small enclave of people cares whether a module gets a 16 or 17,
I'll be shocked.
Personall
On 20 Jul 2006, at 00:38, demerphq wrote:
[snip]
The whole reason this thread started was that i suggested that test
descriptions be mandatory, as they were in my opinion the best way to
resolve this problem.
[snip]
How about something like:
---
package Test::StrictName;
use Test::Builder;
us
On 22 Jul 2006, at 15:30, Fergal Daly wrote:
[snip]
There are two reasons to use subroutines.
1 to group related code in a single unit with a descriptive name
2 code reuse - calling the subroutine from multiple places
Your example is #1 and T::B currently supports it perfectly. It does
not sup
On 3 Aug 2006, at 14:20, Ovid wrote:
What I would prefer to do is something like this:
prove t/test_class_tests.t path/to/test/class.pm
for consistency with perl maybe add a -M option to prove so you could
have:
prove -Ipath/to -Mtest::class t/test_class_tests.t
?
Adr
On 3 Aug 2006, at 14:40, Michael Peters wrote:
[snip]
Actually, the way I use Test::Class is to have one script per
class. That way I
can just run one if I want to.
Yeah - but then you lose the start up time advantage when you run
multiple classes in the same process.
(not that it's a ba
On 6 Aug 2006, at 13:41, Nicholas Clark wrote:
[snip]
My view is that because the actual output of the code isn't well
specified
(sadly nothing that new there either), if we write functional tests to
verify that the behaviour we desire is present, then we're actually
killing
two birds with o
On 6 Aug 2006, at 14:27, Sagar Shah wrote:
[snip]
No, I think you're absolutely right. I've also long held the view
that
functional tests provide a better cost:benefit return.
Unit tests do have their advantages, but if I had to chose between
writing unit & functional tests (say because of r
On 8 Aug 2006, at 04:58, A. Pagaltzis wrote:
* Daniel Risse <[EMAIL PROTECTED]> [2006-08-08 05:10]:
So something like this:
use Test::Simple 'no_plan';
use Test::Terminated;
# insert tests here
# signal we made it to the end okay
terminated_ok();
It occurs to me that you don’t even need t
On 8 Aug 2006, at 23:34, A. Pagaltzis wrote:
* Ovid <[EMAIL PROTECTED]> [2006-08-08 08:55]:
Without the test plan, the bottom bar is merely red or green.
Making no argument about the test plan, I would say that this is
how it should be anyway. You’re either passing your tests or you
aren’t.
On 8 Aug 2006, at 20:06, chromatic wrote:
On Tuesday 08 August 2006 00:30, [EMAIL PROTECTED] wrote:
Following in the footsteps of the recent discussion on extending
no_plan
to cover the case of us making sure the script actually finished
'normally', it occurred to me that another thing that
On 11 Aug 2006, at 09:25, Ovid wrote:
After thinking about Daniel Risse's idea for a Test::Terminated
module, I've been thinking this is something which should be
incorporated directly in TAP. Plans become optional but the last
line of the TAP output MUST be something like:
tests finis
On 14 Aug 2006, at 21:53, Ovid wrote:
[snip]
My personal thought is that either Andy Lester or Schwern start
such a mailing list. Then we need to contact the major players
from other languages and get them to join and see how we can make
TAP a more widely accepted protocol. We know the ben
On 15 Aug 2006, at 19:14, Michael G Schwern wrote:
On 8/15/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
To be honest, I'm not entirely sure that I could come up with a
really convincing argument for TAP for an audience using JUnit,
TestNG and similar...
Do we have a convinci
On 15 Aug 2006, at 19:14, Michael G Schwern wrote:
[snip]
The separation of the display code from the tests themselves is a
bonus. Though one would have to check with folks who actually use
XUnit to be sure this is a problem
[snip]
I don't think it is. In things like JUnit and TestNG the tes
On 15 Aug 2006, at 19:29, Michael Peters wrote:
[snip]
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.
Nothing stopping you doing
On 15 Aug 2006, at 21:31, Fergal Daly wrote:
[snip]
XUnit allows heirarchical grouping, TAP does not. DUnit (Delphi's
XUnit) comes with a GUI that shows you a tree of tests/groups,
[snip]
It's worse than that actually. These days things like TestNG allow
you to cut up tests into arbitrary g
On 15 Aug 2006, at 22:08, Fergal Daly wrote:
[snip]
Just as an aside, allowing this kind of nested structure (with nested
plans) solves many of the plan problems that have been brought up
recently. Last time I brought it up I was told YAGNI but if you want
TAP to be used for XUnit then you are g
On 15 Aug 2006, at 22:19, Collin Winter wrote:
[snip]
In my experience, the
more important hierarchical information is of the form
$module_name.$test_case_name.$test_method_name, which TAP can handle.
[snip]
How?
Adrian
On 15 Aug 2006, at 23:39, Ovid wrote:
[snip]
That threw me off when I first encountered jUnit. For much of the
testing world, a 'test' is a collection of one or more asserts
which verifies that a particular feature behaves the way that it
should. So the following from Test::Class will con
On 16 Aug 2006, at 14:45, Geoffrey Young wrote:
[snip]
I dunno, but I think the ability to
integrate like this is something that would make a killer feature if
folks figured out how to leverage (and market) it.
The problem is that the test runners for some frameworks are "cooler"
than Test::
On 16 Aug 2006, at 19:38, A. Pagaltzis wrote:
[snip]
I don’t know about you, but I tend to prefer a well-defined and
simple wire formats over APIs. :-) In a sense, it’s declarative,
rather than imperative. Integration of heterogenous systems is
much easier that way – even subsystems for which n
On 14 Aug 2006, at 21:53, Ovid wrote:
[snip]
If anyone likes this idea, I've been accepted to attend Google's
Automated Testing Conference in London (http://
googleresearch.blogspot.com/2006/04/our-conference-on-automated-
testing.html) and I can see what I can do to recruit people. (I was
On 20 Aug 2006, at 17:13, A. Pagaltzis wrote:
[snip]
* Adrian Howard <[EMAIL PROTECTED]> [2006-08-17 09:55]:
You're right it can be a bonus. But to sell that to a group of
people who already have something that works very well, is
already integrated with their IDE, continuous
On 21 Aug 2006, at 15:48, Ovid wrote:
- Original Message
From: Adrian Howard <[EMAIL PROTECTED]>
Of course this issue is nothing to do with any intrinsic property of
TAP. There's nothing stopping TAP being integrated much more tightly
- there just needs to be somebody wit
On 21 Aug 2006, at 17:43, Ovid wrote:
[snip]
If I've spent a lot of time building something that is deemed
unsuitable for the future direction of TAP and the testing
framework, I really don't want to continue working on it.
Is it useful to you?
If it *is* suitable but needs some work, I'
On 21 Aug 2006, at 19:52, Ovid wrote:
- Original Message
From: Joe McMahon <[EMAIL PROTECTED]>
Ovid, I currently need a good TAP parser, and I'm settling on yours
as *my* standard, anyway. It would seem futile to write yet another
one when I've got yours to work with. I will certainl
On 21 Aug 2006, at 20:18, Ovid wrote:
- Original Message
From: Adrian Howard <[EMAIL PROTECTED]>
A thought just occurred anybody fancy doing a mini hackathon on
TAPish stuff at YAPC::EU?
Sold! I have some issues I need to work on and TAPx::Parser needs
some help, to
On 25 Aug 2006, at 09:04, Vishal Mehta wrote:
[snip]
1) What is the role of Perl in testing?
[snip]
It's a programming language.
People use perl to test programs written in perl.
Since perl's testing framework is platform agnostic people sometimes
use perl to test programs written in
On 25 Aug 2006, at 16:06, brian d foy wrote:
[snip]
People use Perl to test. No need to say what they test. Plenty of
people use Perl to test programs written in any other language, or
even
to test hardware, networks, and other non-programmy sorts of things.
I thought:
Since perl's testing
On 6 Sep 2006, at 14:33, Ovid wrote:
- Original Message
From: Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]>
Hmm, that's curious. However, if it's undocumented I would argue
against
supporting it right now. What benefit does it gain us?
This comes from the Good Old Test.pm modul
On 8 Sep 2006, at 01:52, Michael G Schwern wrote:
Adrian Howard wrote:
Maybe this is the right time to think about mechanisms supporting
different versions of the TAP protocol?
http://perl-qa.yi.org/index.php/TAP_version
I meant in the context of Ovid's TAPx::Parser code.
Rather
On 11 Sep 2006, at 14:02, Ovid wrote:
Last week I was at a testing conference with Acme and he came up
with the idea of installing tests. He looked into hacking
Module::Build and ExtUtils::MakeMaker. He also considered hacking
CPAN.pm and CPANPLUS.pm. While I don't know if he plans to
On 13 Sep 2006, at 05:37, Michael G Schwern wrote:
[snip]
(For the sarcasm impaired, if you're just going to store the whole
post-install source tarball you might as well just grab it from
CPAN again)
[snip]
Isn't the post-install source tree potentially different in useful
ways from the
On 13 Sep 2006, at 19:28, Michael G Schwern wrote:
Adrian Howard wrote:
On 13 Sep 2006, at 05:37, Michael G Schwern wrote:
[snip]
(For the sarcasm impaired, if you're just going to store the whole
post-install source tarball you might as well just grab it from CPAN
again)
[snip]
Isn&
On 17 Sep 2006, at 23:25, Fergal Daly wrote:
[snip]
So while I don't think I'd vote for stopping the install because of an
expected pass, I don't think it's ever a good sign. The idea of
something working "better" than than the author expected is a bit
dubious.
[snip]
I'm not so sure about tha
On 18 Sep 2006, at 17:39, chromatic wrote:
On Monday 18 September 2006 03:26, David Golden wrote:
I think authors need to aim to have the quality of test code be
the same
as the quality of module code. (Though I'll admit that I don't
always
live up to that standard myself.)
At some poi
On 22 Sep 2006, at 16:51, David E. Wheeler wrote:
On Sep 21, 2006, at 17:43, Michael G Schwern wrote:
The hack will only work for Test::Builder based tests. I said
this last month when it came up. You could write a hack for
Test.pm too, but not everyone uses Test.pm either. You're going
On 19 Sep 2006, at 10:36, David Cantrell wrote:
Adrian Howard wrote:
Yeah - it's something I've noticed over the last year or so. I'm
talking to people less about "you should write tests", and much
more about "you should write /good/ tests".
Wh
On 22 Sep 2006, at 09:11, Ovid wrote:
I don't have time to track this down, but I've noticed the
following when I run my Test::Class tests through prove:
[snip]
As you may notice, you see the diagnostics from the TODO failures.
As Schwern has noted repeatedly:
The user should not see
On 22 Sep 2006, at 15:43, Ovid wrote:
Hi all,
So here's the thought. If we accept that TAPx::Parser might
override certain bits of Test::Builder's behavior, what about the
following *completely optional behavior that you must explicitly
request from TAPx::Parser* (borrowing from earlier
On 26 Sep 2006, at 14:59, Ovid wrote:
[snip]
(You know, you could probably use that to do interesting things
like caching the last time a given developer ran tests. Hmm, why
anyone want to do that?)
[snip]
So you can do interesting things like run tests in "most recently
failed" order?
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
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 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 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 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 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 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 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
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 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
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 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 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 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 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
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 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
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 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
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 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 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
101 - 200 of 278 matches
Mail list logo
