-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 6/26/14, 3:18 PM, 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
>> incompatibilities should never* happen.
>
Huzzah!
On 5/1/13 3:38 PM, Paul Johnson wrote:
> In accordance with the terms of my grant from TPF this is the monthly
> report for my work on improving Devel::Cover covering March 2013.
>
> Sorry for the delay in this report. Most of March and all of April has been a
> very busy time for me ou
On 4/27/13 3:41 PM, Karen Etheridge wrote:
> On Sat, Apr 27, 2013 at 03:22:31PM -0700, Michael G. Schwern wrote:
>> No, it's not Test::Exception's fault.
>
> No, I understand -- I just prefer Test::Fatal, so I convert dists when
> seeing them and I also have a tuit to spare.
Oh, ok then.
On 4/27/13 2:33 PM, Karen Etheridge wrote:
> On Sat, Apr 27, 2013 at 10:19:44AM -0400, Ricardo Signes wrote:
>> Test::Exception fails, which breaks a lot of my basic toolchain from
>> installing.
>
> Which dists? I'll convert them to Test::Fatal.
No, it's not Test::Exception's fault. They h
0.98_05 is a release candidate for 0.99. I would say this is the last
stable release of Test::More before 1.5.0 but hahahaha I won't say that.
https://metacpan.org/release/MSCHWERN/Test-Simple-0.98_05/
There hasn't been a stable release in two years, so there's likely to be
code which has wrapped
On 4/18/13 6:42 AM, Karen Etheridge wrote:
> On Wed, Apr 17, 2013 at 11:58:55AM +0200, Philippe Bruhat (BooK) wrote:
>> I would like to collect your impressions about what worked and what
>> didn't, what was missing, what you want for next year
>
> For those of us participating remotely, some smal
On 4/15/13 7:06 PM, Jens Rehsack wrote:
> On 15.04.13 18:56, Michael G. Schwern wrote:
>> TL;DR version...
>> IMO we only need to clarify what "conflicts" means and what actions CPAN
>> tools should take.
>>
>> We talked in the Consensus Dome about th
I use a hackathon to...
* Sync up with what else is going on
* Make long standing hard/bikeshed/warnock'd decisions
* Remind myself that there are people behind the emails
* Be a resource for Test::*, TAP, MakeMaker, build...
* Hack away at code, particularly long standing issues which
haven't b
On 4/15/13 7:02 PM, Mike Doherty wrote:
> This requires Moose maintainers to know about all the things their
> releases break. Have you considered reversing the directionality so
> MooseX::Blah knows about the things which break it? That seems like a
> more likely scenario to me, and lets the right
TL;DR version...
IMO we only need to clarify what "conflicts" means and what actions CPAN
tools should take.
We talked in the Consensus Dome about the need for and meaning of the
"conflicts" relationship in the CPAN::Meta::Spec.
https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec
IIRC the co
le runtime had to be patched, note it as a conflict.
We did the work primarily on an EtherPad and in the Test-More Github
issue tracker by a small team of remote and local developers.
Karen Ethridge (ether)
James Mastros (theorbtwo)
Colin Newell
Daniel Perrett (pdl)
Michael G Schwe
I'd like people's opinions on a possible downgrade of Test::Builder 1.5
in an attempt to make getting a stable release out easier. It has to do
with whether we keep minor changes to the TAP formatting as the new
default or replicate Test::Builder's current quirks.
https://github.com/schwern/test-m
On 3/21/13 3:39 PM, Adrian Howard wrote:
> 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
>&g
On 3/21/13 11:23 AM, Mark Keating wrote:
> On 19/03/2013 08:20, Ovid wrote:
>> This really frustrates me because I've attended every QA-hackathon to
>> date and we applied for my visa renewal in November :(
>
> That is massively frustrating and we have already booked a room in your
> name, i think
On 2012.8.15 4:24 AM, Karen Etheridge wrote:
> On Sat, Aug 04, 2012 at 04:57:42PM -0700, Michael G Schwern wrote:
>> Executive Summary: If you're using Test::Builder::Tester to test your Test
>> module, switch to Test::Tester. It will make the transition to Test::Builder
>&
On 2012.8.15 2:43 AM, Buddy Burden wrote:
> Well, I say that it's a bit of a PITA, but I'll add it to my TODO
> list. I recall now that the skip/SKIP thing is what was causing some
> CPAN Testers failures for Test::File, so I guess I'l just switch it
> over to Test::Tester and that'll solve it, eh
On second thought, this has to be turned on explicitly for implementation
reasons, so there's no backwards compat issue. "use Test::SharedFork" would
simply turn on that feature in Test::Builder 1.5 providing a way to smoothly
transition between 0.9x and 1.5.
See https://github.com/schwern/test-m
Executive Summary: I propose Test::Builder 1.5 makes writing tests using fork
as easy as writing tests using threads is. Test::Builder will handle the
coordination for you. Downside: this breaks existing behavior. Rebutal: if
you're testing with fork your tests are probably broken with Test::Bu
Executive Summary: If you're using Test::Builder::Tester to test your Test
module, switch to Test::Tester. It will make the transition to Test::Builder
1.5 smoother and avoid future breakage due to TAP formatting changes.
A lot of the work done fixing CPAN Test::* modules to be compatible with
Te
Moving along the trail of getting Test::Builder 1.5 ready (and CPAN ready for
Test::Builder 1.5), the next step is to fix the Test modules which are
failing. While they fail, large chunks of CPAN cannot be tested.
I've set up issues for the known failures. Some of them are probably very
easy, so
On 2012.7.27 12:48 PM, Jeffrey Thalhammer wrote:
> I just discovered that version.pm always treats version numbers with an
> underscore as less than the equivalent version number without the underscore.
> So "6.63_02" is less than "6.6302". Is it it just me, or does that seem
> crazy?
> Dealing w
On 2012.7.11 2:39 PM, Daniel Perrett wrote:
> I may have missed the point here, but would it be sufficient to have
> two flavours of diagnostic calls, distinguishing between pre-test
> diagnostics (`forewarn()`) and post-test diagnostics (`reflect()`), or
> is the problem that ok() must be a single
On 2012.6.1 5:40 AM, Steffen Schwigon wrote:
> I am about to upload Test::TAPv13. I also did an prepan entry for that.
>
> PrePAN: http://prepan.org/module/429En4oFbn .
> URL: https://github.com/renormalist/Test-TAPv13
> Synopsis:
>
>use Test::TAPv13 ':all'; # must come before Test::M
On 2012.6.24 7:06 AM, Shlomi Fish wrote:
> [QUOTE]
> t/01basic.t . ok
>
> # Failed test 'error parsing non-existent does_not_exist.xml'
> # at t/02parse.t line 238.
> # 'Could not create file parser context for file
> "does_not_exist.xml": No error at
The fifth alpha for Test::Builder 1.5 has been released. It contains work
from Matthew Horsfall, Peter Rabbitson, geistteufel, Karen Etheridge, Michael
Schwern and others.
It primarily addresses threading issues and regressions discovered via testing
CPAN modules.
https://metacpan.org/release/MS
I've cut three tasks related to the use_ok() discussion, should people be
interested in doing some small work to that end.
Revert use_ok() back to its 0.98 features
https://github.com/schwern/test-more/issues/287
Discourage use_ok() in the docs
https://github.com/schwern/test-more/issues/288
Add
On 2012.4.14 4:03 AM, Aristotle Pagaltzis wrote:
>> Which is a bit of a mouthful. Providing a function to get at the
>> history object would make a bunch of test state introspection easier.
>>
>># That looks pretty good.
>>END { BAIL_OUT() unless test_history->test_was_successful }
>
> I
On 2012.4.11 1:01 PM, Aristotle Pagaltzis wrote:
>> Unless I'm mistaken, Test::AutoBailOut is doing to need a global
>> $SIG{__DIE__} handler or override CORE::require or add something to
>> @INC or try to parse exception messages or something like that. Any
>> of those have global side effects whi
On 2012.4.11 1:45 PM, Andy Lester wrote:
> test_requires is Module::Build only, right? I don't use Module::Build.
It was just added to ExtUtils::MakeMaker but I don't know when a stable will
be released.
--
There will be snacks.
On 2012.4.11 11:43 AM, Eirik Berg Hanssen wrote:
> If this fails, the test script will terminate immediately:
>
> * I won't get to know if any of the other modules loaded correctly, or how
> they fail. Less of the interesting output.
> * And there will be no BAIL_OUT, so the rest of the tests w
On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
> * Michael G Schwern [2012-04-11 18:35]:
>> Nope, too much magic for too small a use case.
>
> And faithfully duplicating `use` would be less so? :-)
This discussion is about backing away from that. The most magical bits of
us
On 2012.4.11 9:39 AM, Andy Lester wrote:
> In this example:
>
> BEGIN {
> use_ok( 'App::Ack' );
> use_ok( 'App::Ack::Repository' );
> use_ok( 'App::Ack::Resource' );
> use_ok( 'File::Next' );
> }
> diag( "Testing App::Ack $App::Ack::VERSION, File::Next $File::Next::VERSION,
> Perl
On 2012.4.11 7:35 AM, Andy Lester wrote:
> So is there ANY legit use for use_ok()?
Yes. Sometimes you want to conditionally test if a module can be loaded and
its import does not blow up.
It's a convenience function so it can be more easily understood what's going
on and we don't each write it a
On 2012.4.11 8:45 AM, Aristotle Pagaltzis wrote:
> Then you simply do this:
>
> use Test::More tests => 1;
> use Test::AutoBailOut reason => 'Could not load prerequisites';
> use Config;
>
> use Test::Trap::Builder::TempFile;
> use Test::Trap::Builder::SystemSafe;
> use Te
On 2012.4.10 6:21 PM, The Sidhekin wrote:
> * How would you rewrite a test script such as my own
> http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
> that it does not use use_ok()?
use Test::More tests => 1;
use Test::Trap::Builder::TempFile;
use Test::Trap::Builder:
On 2012.4.10 2:52 PM, Mike Doherty wrote:
> On 12-04-10 05:20 PM, Paul Johnson wrote:
>> On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
>>> 2. Should use_ok() be discouraged in the documentation?
>>
>> I'm very much in favour of this.
>
&
In a series of patches, Father Chrysostomos and I enhanced use_ok() so that it
can apply lexical effects to more closely emulate the real `use`. For example,
use_ok('strict');
Previously this would just load strict and call import, but strictures would
not actually be applied to your scope.
On 2012.3.14 5:49 PM, James E Keenan wrote:
> On a machine where I can only install libraries underneath my home directory,
> I today tried to install and use Devel::Cover. After considerable effort, I
> was able to install Devel-Cover-0.79. But when I went to use it in
> conjunction with 'prove'
On 2012.2.7 6:29 PM, Jeffrey Thalhammer wrote:
> I'm working with a group of Perl developers with various backgrounds and
> skill levels.
> We have instituted a fairly effective code inspection process, but we still
> get
> bogged down in debates over what "good code" is. Unfortunately, the
dev
On 2011.12.6 10:56 AM, Cosimo Streppone wrote:
> I wasn't referring to a dependency problem,
> but to the actual code being the same on the
> thing-that-tests and thing-that-is-being-tested.
It would be a problem if they were the same code, but they're not because
TB2::Mouse is a copy of an earlie
On 2011.12.6 1:23 AM, Cosimo Streppone wrote:
> Plus, what would happen if at some point Mouse wanted to
> use TB2 for its test suite?
You might have missed that part of the conversation. TB2 would not depend on
Mouse, it has its own embedded copy. It would work fine.
--
"Clutter and overload
As a result of the discussions, I'm now reconsidering using Mouse in TB2. Its
interesting, it's not for any of the reasons I thought, but for a distressing
encapsulation breech built into Moose.
The main concern is that the fact that we're using Mouse leaks out. We must
document that we're using
You might want to crib from BackPAN::Index. It has a lot of this terminology.
On 2011.12.2 5:21 PM, Jeffrey Thalhammer wrote:
> The context is Pinto, which is yet-another suite of libraries and tools
> for building a private CPAN-like repository.
Does it explode when hit from the rear? No? Jo
On 2011.11.30 12:28 PM, Ricardo Signes wrote:
>> You're patching Test-Simple.
>
> Okay. So, I want to write a third-party test output formatter that emits test
> results in the binary language of my water vaporators. I subclass some core
> formatter with "use parent" and add some methods or some
On 2011.11.30 7:20 AM, Ricardo Signes wrote:
> re: "internal use"
>
> What does "internal" define here? What are the boundaries of the space to
> which TB2::Mouse use is internal?
Like any other "internal use only" .pm file in a CPAN module, it can only be
used by the Test-Simple distribution (T
On 2011.11.30 4:31 AM, David Golden wrote:
> On Wed, Nov 30, 2011 at 6:13 AM, Michael G Schwern wrote:
>> Unfortunately, that would be a circular dependency between Mouse and TB2
>> unless...
>
> Not a complete dependency, though, as one can function without the
> oth
On 2011.11.30 2:04 AM, David Golden wrote:
> On Wed, Nov 30, 2011 at 12:39 AM, Michael G Schwern wrote:
>> There is a 3rd choice, which brings us full circle to where this discussion
>> started. We write TB2::Object [1] to select load Mouse if its available,
>> TB2::Mouse
On 2011.11.29 9:49 PM, David E. Wheeler wrote:
> How much slower will this make running the core tests,
> since neither Mouse nor Mouse::XS will every be available
> there (during development, at core installation time).
Doing some back of the envelope calculations, it looks like an extra minute
a
After the discussion, some pondering and hearing from Goro, I've decided that
TB2::Mouse will be marked for internal use only.
1. People are uncomfortable that I'm shipping a copy of Mouse::Tiny,
let alone making it public.
2. If it's private now, it can be made public later. Can't do it the
011 at 4:02 PM, Michael G Schwern wrote:
>> Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down
>> to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to
>> do NO EXTRA WORK AT ALL to include or maintain it. It just comes with
&g
On 2011.11.25 3:04 PM, chromatic wrote:
> On Friday, November 25, 2011 at 01:02 PM, Michael G wrote:
>> We did it once with Test::Harness::Straps, though not nearly that well
>> thought out, and it worked.
>
> Do you know anyone (besides me) who used it?
I know I dealt with some DarkPAN users, b
Keeping this all in perspective, TB2::Mouse is one 110K file (compressed down
to 25K) with no POD. It's part of the Test-Simple distribution. p5p has to
do NO EXTRA WORK AT ALL to include or maintain it. It just comes with
Test-Simple like any other .pm file in Test-Simple.
If I didn't bring it
On 2011.11.23 12:49 AM, Ovid wrote:
> As an aside, while I'm sure that Schwern is using far more
> than just roles, Role::Basic already handles multiple roles,
> is forwards-compatible with Moose::Role and it adheres much
> more closely to the traits spec, particularly with regards
> to the commuta
On 2011.11.23 12:15 AM, Eric Wilhelm wrote:
> Was there some work in Moose to generate and load pre-cooked classes for
> startup-time basics like the accessors and roles? It seems like being
> able to do that work once during `make` would be a big win.
I think that was wrt pre-cooking Moose's m
On 2011.11.22 8:06 PM, David Golden wrote:
> Attributes -- leaving aside types and coercion -- are you just talking
> about the sugar?
Mostly, and the sugar is very helpful, but not all of it.
There's also the potential runtime performance win. Mouse XS accessors are
significantly faster than pu
On 2011.11.22 11:02 AM, Eric Wilhelm wrote:
>> By being THE testing framework, it places an upper bound on how fast
>> anyone's tests can be. 10 .t files per second, no faster. That
>> sucks.
>
> I agree. But, with XS mouse, you're only cutting the startup time to
> 0.07s from 0.09s, correct?
On 2011.11.22 11:22 AM, David Golden wrote:
> On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm wrote:
>> Is there a way to remove some of the work Mouse is doing at startup?
>> What is it doing?
>
> How much of Mouse is needed? Could Moo be used? (I ask without
> having read the details of the OO
Threads are now working in Test::Builder1.5. That's the last missing feature,
Test::Builder1.5 can now do everything 0.98 can! Huzzah!
If anyone want to see how much working with threads suck, just have a look at
this hack.
https://github.com/schwern/test-more/blob/Test-Builder1.5/lib/TB2/Thread
On 2011.11.21 8:30 AM, David Golden wrote:
> My bigger concern would be inclusion of Mouse in core as a dependency,
> since the direction of Perl seems to be to have fewer core modules,
> not more. I'd run that discussion by p5p/Ricardo before getting too
> tied to Mouse.
Mouse won't be in the co
On 2011.11.21 4:07 AM, David Cantrell wrote:
> But then how often does one need to 'use Test::More'? Not enough to
> bother optimising it, I'd say.
In every single .t file that gets run by just about everybody.
By being THE testing framework, it places an upper bound on how fast anyone's
tests c
I did some profiling and easy optimizations which sped things up quite a bit,
but it didn't translate into real world improvements. Turns out the real
problem is startup time.
use Test::More;
0.98
real0m0.021s
user0m0.016s
sys 0m0.004s
1.5
real0m0.092s
user0m0.083s
sys
Test::Builder1.5 is slow. How slow? About 3x slower than 0.98. Enough to
significantly impact test performance. For example, Spiffy takes 1 second
with 0.98 vs 3.3s with 1.5.
I deliberately didn't do any profiling or optimization while the design was
coming together. This avoided spending tim
On 2011.11.17 4:08 AM, Nicholas Clark wrote:
>> 1) It's not really my goal to make it distributable as a CPAN module,
>>but as just something you copy.
>
> It continues to be my goal to reduce the amount of effort needed to support
> the core. Exposing more of the internals runs counter to thi
Gentlemen, start your smokers!
https://metacpan.org/release/MSCHWERN/Test-Simple-1.005000_001
Thanks very much to the contributors who stepped up:
* James E Keenan
* Jason Galea
* Nóirín Plunkett
* Aaron Crane
* chromatic
* Father Chrysostomos
* Larry Leszczynski
* Michael Ludwig
* Mike Doherty
*
Subtests are now 100% operational in Test::Builder1.5.
It slipped in place very nicely with the new event system, which makes me very
happy, and it's much simpler than it used to be. The only vestige of the old
system I had to retain was tracking TODO tests since that's still done in the
Test::Bu
On 2011.11.16 4:19 PM, James E Keenan wrote:
> Should we proceed on the assumption that this specifies v12?
>
> http://testanything.org/wiki/index.php/TAP_specification
>
> ... and that this specifies v13?
>
> http://testanything.org/wiki/index.php/TAP_version_13_specification
No, not for our p
I have an important task for getting Test::Builder 1.5 stable.
Test::Builder 1.5 outputs TAP version 13. There are minor formatting changes
including a TAP version header and changes to the ending commentary.
A lot of tests look at this output and so they break. Rather than make
everybody chang
First thing to clarify, I don't really envision this being turned into a CPAN
module. That would be directly against its purpose.
The primary purpose here is to separate and focus development and provide a
point for module authors to copy it into their project.
It probably will *not* be released
On 2011.11.15 6:40 AM, Leon Timmermans wrote:
> I'm not seeing the point really. By this logic we can reduce all
> frameworks on CPAN to some three letter acronym. To be honest I don't
> think Test::Builder is used directly often enough to justify that.
Test::Builder was just one monolithic module
On 2011.11.15 1:14 AM, Buddy Burden wrote:
> Okay, just to follow-up in case anyone cared what the resolution on
> this one was, changing the loop full of ok()s to one giant pass() or
> fail() per loop fixed _everything_. Plus it runs a lot faster now. I
> know I've seen test suites that do thous
On 2011.11.15 1:01 AM, Buddy Burden wrote:
> I did not know this ... just to be super-clear, obviously I know that
> if I have script.pl and it starts with
>
> #! /usr/bin/perl -w
>
> and I make it executable and run it directly, I get perl -w. But
> you're saying that even if I type:
>
>
I'd like a smoker setup which can do two things:
1) Run smokes for all the Test:: modules.
2) Compare the results between two different installed versions of Test::More.
This will allow me to smoke Test::Builder 1.5 against CPAN, see what it's
broken and try to fix it.
I've never used the CPAN s
Having a parallel and featureful testing system is very useful. I use it to
test Test::More (in the Test-Builder1.5 branch). Others might find it useful
to do the same.
t/test.pl is very important to the Perl core tests, but it is largely
undocumented and untested. Going through the p5p process
On 2011.11.14 12:41 AM, Philippe Bruhat (BooK) wrote:
> I'm more annoyed with the version number being part of the name.
> Even if I can understand the reason why (CPAN only knows one way to
> upgrade: up).
I used to be with you there.
I've since found it's a remarkably simple and foolproof way t
I have written "Test::Builder2" more times than I can count.
Wait, I can count them. It occurs at least 1280 times in the distribution.
That's 18,000 keystrokes. 19,000 if you count shift. It gets a little
tiresome. That's just the current count, who knows how many times I've
retyped it.
In t
On 2011.11.13 8:39 AM, Reini Urban wrote:
> I've come around your hammering lately and had this idea:
>
> Cannot CPAN add logic to avoid downloading your new versions on older
> releases?
Yes, but it is non-trivial.
It would requiring creating a new index which supplies modules and versions
for
It's that time again! Time when I hammer the last few nails in the coffin of
a version of Perl.
By which I mean, the next major release of Test::More (aka Test::Builder1.5)
will support 5.8.1 and up. ExtUtils::MakeMaker will probably go that way,
too. This effectively cuts off most of CPAN from
On 2011.11.10 7:44 PM, chromatic wrote:
On Thursday, November 10, 2011 at 05:57 PM, Michael G wrote:
If you don't want global warnings, explicitly turn them off with BEGIN { $^W
= 0 }.
I thought the argument that test modules should set global policy unilaterally
died out when I made Test::Moc
On 2011.11.10 4:59 PM, Buddy Burden wrote:
chromatic/Merjin,
Not "use warnings" but the -w command line flag -- the non-lexical, warnings-
on-everywhere one.
no change whatsoever. I've now added -w to all #! lines in the t files
Does that do anything? I didn't think prove respected the sh
On 2011.11.10 7:15 AM, H.Merijn Brand wrote:
Yes, there indeed is a core
(gdb) where
#0 0xc0258c70:0 in free+0x1d0 () from /usr/lib/hpux64/libc.so.1
#1 0x4017f7e0:0 in Perl_safesysfree () at util.c:262
#2 0x400d0ab0:0 in perl_destruct () at perl.c:871
#3 0x400
Subtests work in Test::Builder2. The design we worked out and documented here
is implemented.
https://github.com/schwern/test-more/wiki/Subtest-Design
Test::Builder2->subtest exists and the TAP formatter understands subtest events.
However, it has not yet been plugged into Test::Builder's subt
On 2011.11.6 5:20 AM, James E Keenan wrote:
>> You're absolutely correct that it has no docs. Some of this is to avoid
>> using
>> the inline POD feature, in case it breaks while developing the core. But it
>> could be documented either in comments, or POD in an __END__ block, or (the
>> safest)
On 2011.11.5 5:23 AM, James E Keenan wrote:
> Does anyone actually use t/test.pl? What does it do? What is it for?
test.pl has the classic meaning of pl meaning "Perl Library" not the
bastardized "Perl Executable". It's a simpler, parallel alternative to
Test::More written using simpler Perl fe
On 2011.11.5 12:37 PM, Aristotle Pagaltzis wrote:
> * Michael G Schwern [2011-11-04 04:45]:
>> When doing delegation I have a documentation dilemma: do the API docs
>> go in the delegator or the delegate?
>
> This is the classic reference vs tutorial dilemma, isn’t it?
On 2011.11.3 8:44 PM, Michael G Schwern wrote:
> When doing delegation I have a documentation dilemma: do the API docs go in
> the delegator or the delegate?
To answer my own question, I've decided to do the best of both worlds.
I will document each object's native methods in i
When doing delegation I have a documentation dilemma: do the API docs go in
the delegator or the delegate?
In this case it's Test::Builder2::TestCase which delegates to a stack of
Test::Builder2::EventCoordinator objects. The user will primarily interact
with TestCase objects. Only rarely should
On 2011.11.2 7:24 PM, James E Keenan wrote:
> On 11/2/11 4:35 PM, Michael G Schwern wrote:
>> Here's all the current gardening tasks.
>> https://github.com/schwern/test-more/issues?labels=Gardening%2CTest-Builder2&sort=created&direction=desc&state=open&page=
Designing the subtests made me realize a few things about the event system
that would be better done a little differently. Mostly renaming things.
It would help me immensely if people could do these refactorings so I can
focus on the design. They should be straightforward, it's just time consumi
https://github.com/schwern/test-more/wiki/Subtest-Design
I've decided on a complete design for subtests and written it up, mostly to
get it out of my head before I forget it. :-) Please let me know what you
think. Here's a summary...
In short, from a Test::Builder point of view, subtests do tw
On 2011.10.30 11:15 PM, Eric Wilhelm wrote:
> # from Michael G Schwern
> # on Sunday 30 October 2011 20:30:
>
>> The current Test::Builder implementation is a mess and its design
>> cannot go forward. They have to be gotten just right to ensure that
>> not just n
On 2011.10.30 7:21 PM, David Golden wrote:
> I haven't followed the T::B 2 work closely enough, so could I ask you
> to please step back and explain the benefits of T::B 1.5 that is worth
> stepping backwards in terms of capabilities? What I mean is that we
> have TAP::Harness now that processes s
On 2011.10.30 2:58 AM, Adrian Howard wrote:
> I prefer the current subtests system for a few reasons:
>
> * With the new system I would have to re-write TAP streams from other sources
> to match the numbering system of the current stream. This makes more work for
> folk who are pulling in TAP stre
On 2011.10.29 3:51 AM, Fergal Daly wrote:
> It seems like it's impossible then to declare a global plan in advance
> if you use subtests unless you go counting all the sub tests which is
> no fun,
Yes, that's a very good point.
use Test::More tests => 3;
subtest "first" => sub { ... };
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 implemented)
>
> This may be me
On 2011.10.28 6:52 AM, David Golden wrote:
> Without looking at the actual code, I would guess that the complexity
> is implementing subtests while preserving the legacy procedural
> interface that wraps calls to a global singleton.
No, that's not really the problem. It was when Ovid originally i
On 2011.10.28 12:23 AM, Ovid wrote:
> Echo chamber alert: I've often seen long discussions on this list ignore
> the "real world" (though often for good reason). In this case, it sounds
> like there's a consideration of removing a feature from TAP.
No, not removing from TAP but removing support fo
On 2011.10.27 12:36 AM, chromatic wrote:
> I've done this several times. I prefer one method per type of event (hello,
> cheap and easy polymorphism!).
Yeah, that's my thinking. One method for all makes overriding next to
impossible.
> This is also one case in which I find an abstract base cl
tl;dr version: Is it better for event handlers to have one method per type of
event? Or one method to accept all events? Or something else?
Currently event handlers (called EventWatchers) in Test::Builder2 implement
two methods: accept_event and accept_result. accept_result() is a special
cas
On 2011.10.26 12:55 PM, Eric Wilhelm wrote:
> To be specific, I picture the interface as one of:
>
> a) subtest_start() must return the subtest handler object
> (might be a new object, or just $self)
>
> or:
> b) subtest_start() must return the $invocant, $method, %args for
> construc
Adrian forgot to send this to the list.
Original Message
Subject: Re: Do we need subtests in TAP?
Date: Wed, 26 Oct 2011 14:14:31 +0100
From: Adrian Howard
To: Michael G Schwern
Hey there,
On 26 Oct 2011, at 04:56, Michael G Schwern wrote:
> I understand wanting "b
1 - 100 of 1799 matches
Mail list logo
