-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.c
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
om in your
> name, i think we will get Schwern into that room and just pretend he is
> called Ovid - I doubt the hotel will check.
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. ;)
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
>&
x -> 1.5
compatibility layer. The behaviors you're testing with TBT will always be
stuck in the past. Test::Tester also spans 0.x -> 1.5 but it does so with
more grace.
You should be able to leave your Test::Builder::Tester stuff alone, it'll
work, but eventually you're going to want to change them.
--
Robrt: People can't win
Schwern: No, but they can riot after the game.
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.c
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
easy, some are not so easy, and some are really involved.
https://github.com/schwern/test-more/issues?milestone=14&state=open
This is only round one. Once the known Test module failures are fixed, we can
re-smoke and test all the things that can't be tested because of dependency
failures.
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
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/issue
->test_was_successful }
>
> I like that.
Go at it.
https://github.com/schwern/test-more/issues/286
--
package Outer::Space; use Test::More tests => 9;
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
st::Trap::Builder::SystemSafe;
> use Test::Trap::Builder;
> use Test::Trap;
> use if $Config{'useperlio'}, 'Test::Trap::Builder::PerlIO';
>
> no_bailout 'All prerequisites loaded';
>
> Dead simple. Huge swathes of complexity, *puff
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
the core,
modules which help install other modules have always been in that set. The
test framework used by 80% of CPAN is squarely in that category. Should it be
thrown out because of one file?
If I didn't point it out, nobody would have known it was there.
--
Robrt: People can't win
Schwern: No, but they can riot after the game.
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
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
ssors and there
isn't much to be done about that in Test::Builder2. Performance enhancements
in Mouse itself would be appreciated by all.
I've added a branch called "gonzales" which uses Mouse directly. You can
experiment with that and NYTProf to examine compile time perfor
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/li
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
tters, event system, etc...). Aside from thread support, it is
feature complete and supports all existing features of Test::Builder,
Test::Simple and Test::More.
Tests should continue to work as written. Please report any breakages
at https://github.com/schwern/test-more/i
ps://github.com/schwern/test-more/issues?milestone=5
It looks like Jason Galea stepped up and did the refactorings. There's just
one small one left. I'd appreciate a taker.
https://github.com/schwern/test-more/issues/210
Then I can collapse with the flu while you all knock around the alph
his is really straightforward.
https://github.com/schwern/test-more/issues/219
Write the legacy formatter as a subclass of TAP::v12. This mostly involves
putting the strings TAP uses into attributes and making a subclass of TAP::v12
which changes those defaults.
https://github.com/schwern/
version 12 formatter.
https://github.com/schwern/test-more/issues/215
https://github.com/schwern/test-more/wiki/Preferred-workflow
It's a mildly difficult task, mostly because the v13 formatter does things
which really should be done in a superclass, but it's way easier than trying
to do it in Te
o get people to work on a single file Perl library than it
is to get them to patch the Perl core. In its own project, I can hand a
newbie a URL like this and say "pick one of these and do it!"
https://github.com/schwern/test-more/issues?labels=Easy
>> t/test.pl is very important to
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
like to see 5.6 compatibility retained, they can contact me
about sponsoring the extra work for continued maintenance.
Thanks to Sarathy and rgs for some great and long lived releases! It's been a
good eight years.
Schwern
Slayer of Pseudo-Hashes
Defender of Lexical Encapsulation
Destroyer of Perl Versions
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::Builde
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=
time consuming.
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=1
Thanks!
--
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
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, s
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 1868 matches
Mail list logo
