On 27 June 2014 11:50, Fergal Daly wrote:
> On 27 June 2014 07:18, Ricardo Signes wrote:
>> * David Cantrell [2014-06-26T09:19:00]
>>> I understand that Test::Builder::Tester is the way to go these days -
>>> and it's distributed with Test::Builder, so incompatib
r is really nice and easy to use.
>
> Test::Builder::Tester is awful and often requires that you predict the exact
> TAP that will be printed.
>
> I always recommend Test::Tester.
:)
> Fergal, if no one replies, I can take over simply to shepherd patches and make
> releases
Upcoming changes are going to break it (in a fairly easy to paper over
way). I am not involved in Perl at all anymore. If someone wanted to
take it on, I'd be quite happy to hand it over.
Details are in
https://rt.cpan.org/Public/Bug/Display.html?id=96719
F
On 30 October 2011 00:34, Ovid wrote:
> Should have been sent to the list, not just Fergal.
>
> Cheers,
> Ovid
> --
> Live and work overseas - http://overseas-exile.blogspot.com/
> Buy the book - http://www.oreilly.com/catalog/perlhks/
> Tech blog
On 29 October 2011 18: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 their own separate test state (as currently
Anyone can create a comparator for Test::Deep that lives outside of
the module itself. There are a small number of methods that need to be
implemented but it has never been documented. I always thought I would
get around to improving the diagnostic reporting before publishing the
API but _I_ certai
It would be nice if this was a custom comparator for Test::Deep, then
you would be apply the "almost" to lists of arbitrarily complex items
and also conduct that test at any level of the data structure
(including nesting if you feeling really fruity),
F
2011/2/17 Ovid :
> --- On Thu, 17/2/11, Ovi
est::Builder... as
> soon as I patch up Test::Builder to not be quite so in bed with the
> TAP formatter. It's the next thing on my plate.
Great,
F
> On Jan 25, 10:48 pm, Fergal Daly wrote:
>
>
>
>
>
>
>
> > Test::Tester has been doing exactly this for ye
Test::Tester has been doing exactly this for years
http://search.cpan.org/~fdaly/Test-Tester-0.107/
but is very much tied to the Test::Builder guts (by necessity). While
it supports what you have below, the vast majority of the time I just
used the convenience function check_test() which expects
On 16 October 2010 03:59, Ricardo Signes wrote:
>
> Tonight I uploaded Test::Deep 0.108. The changes made are very small, and
> should not affect anyone other than some edge cases in which it should be
> faster.
>
> Many of the open bugs relate to unfortunately named exports like "blessed" and
>
On 16 October 2010 21:32, Hans Dieter Pearcey wrote:
> On Sat, 16 Oct 2010 20:29:32 +0100, Fergal Daly wrote:
>> use Test::Deep2 qw($deep); # import the "module" as $deep
>>
>> $deep->is_deeply($foo, $deep->set([1,2,3,4]));
>
> Or, without requir
On 16 October 2010 03:59, Ricardo Signes wrote:
>
> Tonight I uploaded Test::Deep 0.108. The changes made are very small, and
> should not affect anyone other than some edge cases in which it should be
> faster.
>
> Many of the open bugs relate to unfortunately named exports like "blessed" and
>
Thank you!
F
On 29 September 2010 19:39, Ricardo Signes wrote:
>
> This morning I released Test::Deep 0.107
>
> http://search.cpan.org/~rjbs/Test-Deep-0.107/
>
> It has a very small number of changes pulled entirely from the RT queue. I
> will continue to make small releases over the next few
On 25 September 2010 18:55, Andy Armstrong wrote:
> On 24 Sep 2010, at 22:39, Fergal Daly wrote:
> [snip]
>>
>> Thanks. I was hoping to find an active user of the module since they
>> would have a bit of a head-start and motivation so I will leave the
>> door open a
On 24 September 2010 22:12, Shlomi Fish wrote:
> Hi Fergal,
>
> On Friday 24 September 2010 23:00:53 Fergal Daly wrote:
>> For a long time now, I haven't had time to maintain this module. I
>> don't write any perl beyond 1-liners these days and work and family
For a long time now, I haven't had time to maintain this module. I
don't write any perl beyond 1-liners these days and work and family
take up most of my free time. When I do have some time, tweaking
software I don't use any more is not on high up the list.
There are a couple of things that need d
On 12 February 2010 08:58, Steffen Schwigon wrote:
> Fergal Daly writes:
>> BTW, python gets this right
>>
>> from Foo.Bar import Buzz
>> ...
>> Buzz.ThatThingIWanted
>>
>> no danger of name clashes (you can import Buzz as some other name if
>&g
On 10 February 2010 22:46, Ovid wrote:
>> From: Fergal Daly
>
>
>> > Also, some test modules are problematic. For example:
>> >
>> > use Moose;
>> > use Test::Deep;
>> >
>> > That gives you a prototype mismatch warning.
On 7 February 2010 08:45, Ovid wrote:
> I would love feedback (via actual use) of a development version of Test::Most
> available at http://search.cpan.org/~ovid/Test-Most-0.21_04/. If you're not
> familar with it, instead of this:
>
> use strict;
> use warnings;
> use Test::Exception
2009/3/17 Adrian Howard :
>
> 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
2009/3/16 Michael G Schwern :
> Fergal Daly wrote:
>> Alternatively, the plan is a meta-test, a test for your testing code.
>> It is the equivalent of putting
>>
>> is($tests_run_count, $tests_i_planned_count)
>>
>> at the end of your test script. Letting th
Great idea. Why didn't someone think of it before and refer to that
page in the first posting in this thread and also in the middle...
F
2009/3/16 Andy Lester :
>
> How about we put up a page somewhere that discusses the pros and cons of
> counting tests, and then whenever the quarterly discussio
2009/3/16 Evgeny :
> Thing is. It just does not matter THAT much.
> The case you describe is fairly rare in the xUnit world, or in any
> world I would guess.
And as I said, I got bitten by it just last week. Another way I've
been bitten is when I've done slightly more complex xUnit stuff where
I c
2009/3/15 Adrian Howard :
>
> 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 prote
2009/3/13 Evgeny :
> I actually put a link to the FAQ at the very first mail I sent.It does not
> address my questions, it gives examples that say "we can't count tests ahead
> of time, its impossible". But I just want you to change the approach from
> "ahead of time" into "realtime" or something .
[oops sending to the list this time]
2009/3/13 Ovid :
>
>
> From: Josh Heumann
>
>> In that case, the way to generate well-formed TAP seems to be to put the
>> END block above the use statement, which either means an end statement
>> at the top in the section of t
2009/1/23 Eric Wilhelm :
> # from Fergal Daly
> # on Friday 23 January 2009 10:18:
>
>>sub test_foo {
>> increment_plan_by(3);
>> ok(foo(1), "foo1 test");
>> ok(foo(2), "foo2 test");
>> ok(foo(3), "foo3 test");
>>
2009/1/23 Eric Wilhelm :
> # from Fergal Daly
> # on Friday 23 January 2009 02:07:
>
>>The point is that you want to declare your intention independently
>>from taking the action. If you declare the plan alongside performing
>>it, then your planning becomes subject to
2009/1/23 Eric Wilhelm :
> # from Ovid
> # on Thursday 22 January 2009 15:01:
>
>>For example, with your code (as I understand it):
>>
>> test {
>> my $manager = Feed::Manager->new($some_uri);
>> foreach my $resource ($manager->resources) {
>> ok my $result = $manager->get($reso
2009/1/22 Eric Wilhelm :
> # from Andy Lester
> # on Thursday 22 January 2009 11:35:
>
>>> Perhaps I'm being unclear. I do not find either 'no_plan' or 'plan'
>>> to be useful in their current state.
>>
>>Yes, but many others do.
>
> Well, are we just accepting limitations and refusing to dream?
I've made an rt.cpan.org ticket out of this which is the best service
I can manage at the moment, sorry,
F
2008/12/23 Gabor Szabo :
> In the Padre project we encountered some strange behavior.
> We recently switched to use Module::Install and we also use Test:::NoWarnings
> in our tests.
>
> It s
2008/9/19 brian d foy <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>, Nicholas Clark
> <[EMAIL PROTECTED]> wrote:
>
>> But it seems that this bug is only fixed as a side effect of that change, and
>> it's not actually tested for. What's the best way to write a test that fits
>> within the cu
2008/8/4 Ovid <[EMAIL PROTECTED]>:
> There's a nasty bug in the latest development version of Test::Differences.
> By applying a patch which allows this to pass (it currently won't):
>
> eq_or_diff { foo => 1 }, { foo => '1' };
>
> It also allows this to pass:
>
> eq_or_diff [ { foo => 1 } ], {
FYI this is not an issue with the latest Test::Deep.
Lessons learned (from this and other problems)
- default exports are just bad
- having an isa() function anywhere is asking for trouble, various
modules will call ->isa on every package they see whether it's really
an OO package or not
The sol
2008/6/10 Gabor Szabo <[EMAIL PROTECTED]>:
> So apparently using Test::NoWarnings isn't that cool
> and mandating it with CPANTS metric is even less cool.
What's the problem with T::NW? Maybe I'm misunderstanding the rest of
this mail but you seem to be looking for something that will catch
warnin
2008/5/15 Ovid <[EMAIL PROTECTED]>:
> - Original Message
>
>> From: Fergal Daly <[EMAIL PROTECTED]>
>> To: Gabor Szabo <[EMAIL PROTECTED]>
>> Cc: Perl QA
>> Sent: Thursday, May 15, 2008 1:15:50 PM
>> Subject: Re: Test::NoWarnings
This is because skip_all exists immediately but Test::NoWarnings has
installed an END block that will run a test anyway. I suppose I should
change T::NW to detect "skip_all" and not run its test but at the
moment there is no T::B API for detecting "skip_all".
MScwern, do you want to add one? What
2008/5/12 Ovid <[EMAIL PROTECTED]>:
> --- Smylers <[EMAIL PROTECTED]> wrote:
>
>> If you believe that (until the TODO is done) foo will consistently
>> return 3, and you wish to be alerted if it suddenly starts returning
>> 4,
>> then surely you can do that with a non-TODO test which checks for its
On 09/04/2008, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 10:14 PM, Fergal Daly <[EMAIL PROTECTED]> wrote:
> > I would say put as much as possible of this outside the Test::
> > namespace and then wrap in a thin Test:: wrapper. I wish I'd
On 07/04/2008, Randy J. Ray <[EMAIL PROTECTED]> wrote:
> All,
>
> Inspired by a u.p.o journal post that Ovid made (
> http://use.perl.org/~Ovid/journal/36010), I've been working on a module that
> will unify testing capabilities for various markup/serialization formats.
> Right now, I plan on:
On 28/03/2008, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 28 March 2008 14:22:32 Gabor Szabo wrote:
>
> > I think chromatic mentioned that you should use FIT for acceptance tests
> > and not for unit tests.
> > May I disagree here.
> > I think every test is a unit test. Just the size of t
On 26/03/2008, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 25 Mar 2008, at 18:31, Ovid wrote:
> > Is there any chance we can produce something viable in Oslo that's
> > likely to solve this problem or is this a low enough priority in most
> > people's minds that they're not bothered? I'm kee
On 15/01/2008, Ovid <[EMAIL PROTECTED]> wrote:
> Test::Harness used to be very limited. We couldn't do a lot with it,
> but when we started testing, most of us didn't do a lot with it. As we
> understood more about testing, we understood better many things we
> wanted. As a result, Schwern poste
especially WRT controlling "make test"
> ** CPAN::Reporter could be made aware of TODO passes.
>
>
> Fergal Daly wrote:
> > On 05/12/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> >> This this whole discussion has unhinged a bit from reality, maybe
x27;m arguing against what has been put forward as good
practice when there are other better practices that are approximately
as easy and don't have the same downsides.
In fairness though these bad practices were far more strongly
advocated in the previous thread on this topic tha
On 02/12/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> 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
If you reply to this, please make sure you reply to the 2 cases
involving the dog, this is my main objection to using TODO tests in
this manner.
On 02/12/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
> > One of the supposed benefits of using TODO is that
http://www.mail-archive.com/perl-qa@perl.org/msg06865.html
has the previous round on this topic. My memory is hazy but my view
was that people are using TODO in strange ways and making this a
failure would break that. The strange way I remember (and has been
brought up again by Chris Dolan) is rel
On 05/09/07, Fergal Daly <[EMAIL PROTECTED]> wrote:
> On 05/09/07, Gabor Szabo <[EMAIL PROTECTED]> 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
&
On 05/09/07, Gabor Szabo <[EMAIL PROTECTED]> 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.
use Test::Deep::NoTest;
print "equal" if eq_deeply($a, $b);
but it's
On 02/09/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Fergal Daly wrote:
> It goes out via the normal TAP stream with all the "ok" and "not ok". That
> is, STDOUT.
>
> Or are you asking about the guts of Test::Builder? I haven't planned
On 01/09/07, Ovid <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Please read and comment on this. Many folks ignore these emails, but
> we're talking about the new version of TAP here! Feedback is
> important.
>
> Schwern: you're specifically copied on this as you maintain
> Test::Simple. If we get t
On 30/08/07, Ovid <[EMAIL PROTECTED]> wrote:
> After doing a bit of thinking about this and chatting with Andy
> Armstrong about this, I've realized that much of the current thought
> about the TAP diagnostics is wrong. We already have much of what we
> want in the TAP line above the diagnostics s
On 05/08/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 5 Aug 2007, at 17:07, Fergal Daly wrote:
> > use Test::More no_plan;
> > use Test::Deep;
>
> Lovely, thanks :)
>
> > my $expect = {
> >name => re(qr/porky/),
> >value => code(s
use Test::More no_plan;
use Test::Deep;
my $expect = {
name => re(qr/porky/),
value => code(sub { $_[0] >= 0 && $_[0] < 10 || (0, "out of range [0,10)")}),
spigot_state => 'active',
};
my $value = {
name => 'My name is porky',
value => 11,# <-- fails
Not a solution to your problem but I just want to point out that the
correct way to write regex tests is
is($re, qr/what I expected/);
and that this will never be upset by changes like demerphq is describing,
F
On 03/08/07, demerphq <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I thought id bring a tric
On 09/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 22:41, Fergal Daly wrote:
> Yes I did. If you want your structured (or any) diagnostics to be
> associated correctly and you want to allow forking you have to tag
> each line with test numbers. If forkin
On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 12:46, Fergal Daly wrote:
> Prepending something to every line is necessary if you want perfect
> multiplexing.
But we don't want that to be part of TAP do we? What's with the
insistence that TAP has
On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 02:07, Fergal Daly wrote:
>> begin
>> begin
>> ok
>> end
>> begin
>> not ok
>> end
>> end
>
> Yes, I said it was nestable but my point is that it once you start
&g
On 08/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 8 Apr 2007, at 01:11, Fergal Daly wrote:
> - it is 1-level deep grouping and so it requires another layer for
> degrouping. Separating the degrouping from the TAP parser confines it
> to a single level of grouping. If you
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 15:37, Fergal Daly wrote:
>> I'd rather just give each thread its own stream and TAP::Parser and
>> mix everything together further upstream in that case. If you want to
>> capture all the TA
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 14:41, Fergal Daly wrote:
> If you're testing web applications, you can fire off forks or threads.
> So instead of serially waiting for each network operation to complete,
> let them run in parallel. Th
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 10:37, Fergal Daly wrote:
> Exactly. And it's clear that you can interleave these 2 streams
> without ambiguity.
>
> If you want to do chunking then you're going to have carefully buffer
>
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Apr 2007, at 01:11, Fergal Daly wrote:
> To address the whatever, BEGIN/END draws you into the XMLish problems
> of waiting for a complete document before acting on the contents and
> even if you avoid this it still m
On 07/04/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 6 Apr 2007, at 23:17, A. Pagaltzis wrote:
> * Michael Peters <[EMAIL PROTECTED]> [2007-04-06 23:15]:
>> Maybe I'm missing something (and if so, please point out the
>> obvious to me) but I can't find a way for a single TAP file to
>> cont
On 29/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Chris Dolan wrote:
> On Mar 28, 2007, at 8:18 AM, Ovid wrote:
>
>> The second test dies but this is ignored. Change My::Test::More to
>> Test::More and the failure is correctly reported. What did I miss in
>> My::Test::More?
>
> If you a
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> use Test::NoWarnings;
I like to use Fewer::Annoying::Dependencies.
I like fewer bugs. I guess we'll just have to agree to differ,
F
On 14/03/07, David Cantrell <[EMAIL PROTECTED]> wrote:
Michael G Schwern wrote:
> First thing is breaks, and probably most important: No warnings.
Any test suite that blithely ignores warnings is BROKEN.
There are two types of warning. First, those which you deliberately
spit out, like "use
On 12/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> Remember, the TAP producer is not the instigator of the conversation.
> The consumer is - it runs the scripts, it requests something to
> produce TAP. The consumer is the the client.
Oh but that&#x
On 12/03/07, Smylers <[EMAIL PROTECTED]> wrote:
Fergal Daly writes:
> On 12/03/07, chromatic <[EMAIL PROTECTED]> wrote:
>
> > On Monday 12 March 2007 10:53, A. Pagaltzis wrote:
> >
> > > Making "either the consumer talks to the producer and the
> &
On 12/03/07, chromatic <[EMAIL PROTECTED]> wrote:
On Monday 12 March 2007 10:53, A. Pagaltzis wrote:
> Making "either the consumer talks to the producer and the
> producer has to implement some complex logic, or the producer
> sticks to the plainest TAP possible" a requirement would just
> lead
On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
Hi Fergal,
* Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 18:00]:
> On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> >How do you set environment variables when the producer lives
> >at the other end of a
On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 00:45]:
> This brings up something else. Future harnesses should probably
> set
>
> I_UNDERSTAND_TAP_VERSIONS="1,5,8,10-22"
>
> so we know what we can out
On 12/03/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 12 Mar 2007, at 12:15, Fergal Daly wrote:
>> Highest version I'd say. I hope we're not expecting such a complex
>> melange of versions that we need to enumerate the ones we support. If
>> say we're s
On 12/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Michael G Schwern wrote:
> Subroutines? I don't know if I follow. Do you mean...
>
> sub foo {
> extend(2);
>
> pass();
> bar();
> pass();
> }
>
> sub bar {
> extend(3);
> pass();
> pass();
> pass();
> }
>
> I believe tha
On 12/03/07, Ovid <[EMAIL PROTECTED]> wrote:
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > How does it do this? I understand that an old harness will not be
> able
> > to parse it - it will be upset by the sub-plans and the dotted test
> > numbers)
>
> Yep. By "backwards compatible" I me
On 12/03/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 12 Mar 2007, at 00:00, Michael G Schwern wrote:
> That's a good idea.
>
> Whether or not you can set a list of specific versions (considering
> them as
> extensions rather than increasing versions) or just a single
> highest version
> is u
On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> You're suggesting that each call to extend the plan verifies that the
> previous plan has been executed fully? That does not allow nesting.
Yes, nesting is what this proposal does which cannot be d
On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-03-11 12:55]:
>> Why does this need a TAP mod? Why not let the producer handle
>> it?
>
> Because then all you can do is a global trailing plan which is
> only half a step
On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> Did group 1 produce 2 tests and group 2 produce 3 or was it the other
> way around?
Why is that important to know?
Because the first case conforms to the plan, the second doesn't.
> Worse,
&g
On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> http://perl-qa.yi.org/index.php/Test_Groups
Rationale?
Why does this need a TAP mod? Why not let the producer handle it?
plan "as_you_go";
plan add => 2;
pass;
pass;
plan ad
http://perl-qa.yi.org/index.php/Test_Groups
F
On 07/03/07, Dominique Quatravaux <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fergal Daly a écrit :
>
> On Monday night I finally broke down and implemented nested blocks
> for Test::Builder [...] The module is broken in many ways but I'll
> p
On 07/03/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 7 Mar 2007, at 12:10, Fergal Daly wrote:
> * nested blocks, each with it's own plan (or no plan)
> eg
> 1..3
> 1 OK
> 2 1..2 # start a block
> 2.1 1..3 # start another block
> 2.1.1 OK
> 2.1.2 OK
> 2
On 07/03/07, Ovid <[EMAIL PROTECTED]> wrote:
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Where does TAP::Tests fit in? D'you mean as an alternative to
> Test::More or whatever?
Yes, an alternative to Test::More. Some thoughts:
Where is it?
* Output everything to STDOUT (thereby avoidin
On 27/02/07, chromatic <[EMAIL PROTECTED]> wrote:
On Tuesday 27 February 2007 13:58, Michael G Schwern wrote:
> What is wrong with the proof-of-concept I proposed?
The lines:
my $real_isa = \&UNIVERSAL::isa;
...
if( ref $obj and eval { $obj->$real_isa("Test::MockObjec
On 22/02/07, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 22 February 2007 12:53, Andy Lester wrote:
> Would there be an option to specify where to find the mocked libs,
> rather than assuming t/lib?
But:
use mocked 't/some_other_lib/' SomeModule;
... isn't all that much shorter t
s may or may not be logged
print $testing ? "testing $i\n" : "not testing $i\n";
pass("pass");
$i++;
} $testing;
}
some_tests(1);
some_tests(0);
some_tests(1);
On 20/02/07, Fergal Daly <[EMAIL PROTECTED]> wrote:
Test::Tester allows you to temporarily d
Test::Tester allows you to temporarily divert test results to another
test result collector (which you can then throw away). It diverts the
results at the method call level so it's like the diverted tests never
ran (it does NOT capture STDOUT, Test::Tester sticks to the documented
interface, rathe
didn't we have this debate before?
F
On 01/10/06, jason gessner <[EMAIL PROTECTED]> wrote:
or 'received' instead of 'got'.
Andy pointing out tap's use of 'got' makes me think prove should end
like:
1/9 tests ain't right.
Test no good. damn.
:)
-jason
On Oct 1, 2006, at 12:18 AM, Andy Lest
On 24/09/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Fergal Daly <[EMAIL PROTECTED]> [2006-09-24 02:20]:
> Here's the problem though "just as likely, no. It depends on
> the author's intent". What is the user supposed to do when
> confronted with a mes
On 22/09/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
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 /
On 23/09/06, chromatic <[EMAIL PROTECTED]> wrote:
On Saturday 23 September 2006 11:30, A. Pagaltzis wrote:
> * Fergal Daly <[EMAIL PROTECTED]> [2006-09-23 19:35]:
> > At least then the user knows there's a problem _before_ he
> > . Remember,
> > this threa
On 23/09/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* Fergal Daly <[EMAIL PROTECTED]> [2006-09-23 19:35]:
> At least then the user knows there's a problem _before_ he
> . Remember,
> this thread is about how the toolchain is really for the user's
> benefit
On 23/09/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* David Golden <[EMAIL PROTECTED]> [2006-09-17 18:10]:
> TODO means "don't have the result of this test affect the
> outcome yet".
Exactly. I think it's just the fact that it's called TODO which
leads people on a garden path.
It's partly the
On 20/09/06, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 20 September 2006 14:35, Fergal Daly wrote:
> HOW CAN THIS POSSIBLY BE A GOOD THING? Compare it with the case where
> we make them real tests
>
> - a prefectly clear run means nothing is broken
> - a ru
The crux of this is #1 and #2 in the first part below and "HOW CAN
THIS POSSIBLY BE A GOOD THING?" in the second part.
Using TODO tests instead of normal tests in the examples below has a
small benefit that can be achieved in other ways and a cost of false
passes and confusion.
On 20/09/06, Mich
On 19/09/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Fergal Daly wrote:
> But there's nothing here for the author to do so it should not be
> marked TODO.
Sure there is. They now know Fribble works and can once again start relying on
it.
To be clear, the scenario
On 18/09/06, Adrian Howard <[EMAIL PROTECTED]> wrote:
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 wo
On 17/09/06, chromatic <[EMAIL PROTECTED]> wrote:
On Saturday 16 September 2006 14:42, Fergal Daly wrote:
> So, a passing TODO tells me that either the author
> - writes bad tests
> - means something else entirely by TODO
> - didn't run the test suite before this relea
1 - 100 of 271 matches
Mail list logo
