Re: Test::Buildder v. Test2 subtests

[Chad Granum]

ok, thanks for trying that, I will look into it when I have time and if
nothing else at least explain why it behaves like it does. If it is a bug I
will fix it.

On Tue, Dec 13, 2016 at 8:18 AM, Ricardo Signes <perl...@rjbs.manxome.org>
wrote:

> * Chad Granum <exodi...@gmail.com> [2016-12-13T11:13:56]
> > I would like to see the results when you use
> > Test2::Tools::Subtest::subtest_streamed() which is the actual
> equivalent to
> > Test::More::subtest().
>
> Thanks for the pointer.  I have tried this and got identical ("bad")
> results to
> Test2::API::run_subtest:
>
>   ~$ perl foo t2ss
>   # Subtest: test
>   not ok 1 - Subtest: test
>   # Failed test 'Subtest: test'
>   # at foo line 24.
>   # Caught exception in subtest: 123 at foo line 13.
>   1..1
>   not ok 1 - subprocess died
>   #   Failed test 'subprocess died'
>   #   at foo line 11.
>   #  got: 0
>   # expected: anything else
>   1..1
>   not ok 1 - Subtest: test
>   # Failed test 'Subtest: test'
>   # at foo line 24.
>   1..1
>   # Looks like you failed 1 test of 1.
>
> Compare to:
>
>   ~$ perl foo t2rs
>   # test
>   not ok 1 - test
>   # Failed test 'test'
>   # at foo line 24.
>   # Caught exception in subtest: 123 at foo line 13.
>   1..1
>   not ok 1 - subprocess died
>   #   Failed test 'subprocess died'
>   #   at foo line 11.
>   #  got: 0
>   # expected: anything else
>   1..1
>   not ok 1 - test
>   # Failed test 'test'
>   # at foo line 24.
>   1..1
>   # Looks like you failed 1 test of 1.
>
> The entire difference appears to be "Subtest: test" vs. "test"
>
> --
> rjbs
>

Re: Test::Buildder v. Test2 subtests

[Chad Granum]

Actually at first glance a possible problem is this: You are using 2
functions that are not intended to be interchangeable.

Test::More::subtest() is a tool intended to run a subtest.
Test2::API::run_subtest() is a helper intended to write tools like
'subtest()'.

I would like to see the results when you use
Test2::Tools::Subtest::subtest_streamed() which is the actual equivalent to
Test::More::subtest().

-Chad

On Tue, Dec 13, 2016 at 8:09 AM, Chad Granum <exodi...@gmail.com> wrote:

> I will have to look into this when I have more time.
>
> On Tue, Dec 13, 2016 at 8:06 AM, Ricardo Signes <perl...@rjbs.manxome.org>
> wrote:
>
>> I've hit a nasty (to me) difference between Test2::API::run_subtest and
>> Test::Builder::subtest.  Shout out to Matthew Horsfall for helping
>> localize the
>> problem.  Here's my trivial reproducer:
>>
>>   #!perl
>>   use strict;
>>   use warnings;
>>   use Test::More;
>>   use Test2::API;
>>
>>   my $code = sub {
>> if (fork) {
>>   wait;
>>   cmp_ok($?, '!=', 0, "subprocess died");
>> } else {
>>   die "123";
>> };
>>   };
>>
>>   my $call = $ARGV[0] ? \::More::subtest : \::API::run_subtest;
>>   $call->(test => $code);
>>   done_testing;
>>
>> When running with Test::More...
>>
>>   ~$ perl foo 1
>>   # Subtest: test
>>   123 at foo line 12.
>>   ok 1 - subprocess died
>>   1..1
>>   ok 1 - test
>>   1..1
>>
>> The die in the subprocess causes the child process to exit nonzero and the
>> tests run normally.  Great!  This is how my tests work.  When I switch
>> them
>> to Test2::API::run_subtest, though, I get this:
>>
>>   ~$ perl foo 0
>>   # test
>>   not ok 1 - test
>>   # Failed test 'test'
>>   # at foo line 17.
>>   # Caught exception in subtest: 123 at foo line 12.
>>   1..1
>>   not ok 1 - subprocess died
>>   #   Failed test 'subprocess died'
>>   #   at foo line 10.
>>   #  got: 0
>>   # expected: anything else
>>   1..1
>>   not ok 1 - test
>>   # Failed test 'test'
>>   # at foo line 17.
>>   1..1
>>   # Looks like you failed 1 test of 1.
>>
>> In the forked code, the die causes the subtest to end in failure *in the
>> fork*
>> meaning we get a repeat result for test 1: one from the child, one from
>> the
>> parent.  Also, the child is now exiting zero instead of nonzero, despite
>> the
>> fact that it threw an exception.
>>
>> It gets worse [for me]!  Above, I had a cmp_ok on $? that failed, so I had
>> duplicate *not ok* results for test 1.  If I replace that cmp_ok with a
>> pass, I
>> get duplicate *conflicting* results for test 1... and then the main
>> process
>> terminates zero.  This means that the test seems to pass if you look at
>> its $?,
>> but the harness sees it as a failure because its total output does include
>> failures (and non-increasing test numbers).
>>
>> Adding Test2::IPC does not help.  The issue is not synchronising test
>> counters,
>> or the like.  It's that I don't want the subprocess's exit to cause a
>> subtest
>> exit in the parent process.  I think that's right: the only process that
>> should
>> turn exceptions into subtest fails is the process that created the
>> subtest.
>>
>> a) am I wrong?
>> b) advice on how to procede?
>>
>> --
>> rjbs
>>
>
>

Re: Test::Buildder v. Test2 subtests

[Chad Granum]

I will have to look into this when I have more time.

On Tue, Dec 13, 2016 at 8:06 AM, Ricardo Signes 
wrote:

> I've hit a nasty (to me) difference between Test2::API::run_subtest and
> Test::Builder::subtest.  Shout out to Matthew Horsfall for helping
> localize the
> problem.  Here's my trivial reproducer:
>
>   #!perl
>   use strict;
>   use warnings;
>   use Test::More;
>   use Test2::API;
>
>   my $code = sub {
> if (fork) {
>   wait;
>   cmp_ok($?, '!=', 0, "subprocess died");
> } else {
>   die "123";
> };
>   };
>
>   my $call = $ARGV[0] ? \::More::subtest : \::API::run_subtest;
>   $call->(test => $code);
>   done_testing;
>
> When running with Test::More...
>
>   ~$ perl foo 1
>   # Subtest: test
>   123 at foo line 12.
>   ok 1 - subprocess died
>   1..1
>   ok 1 - test
>   1..1
>
> The die in the subprocess causes the child process to exit nonzero and the
> tests run normally.  Great!  This is how my tests work.  When I switch them
> to Test2::API::run_subtest, though, I get this:
>
>   ~$ perl foo 0
>   # test
>   not ok 1 - test
>   # Failed test 'test'
>   # at foo line 17.
>   # Caught exception in subtest: 123 at foo line 12.
>   1..1
>   not ok 1 - subprocess died
>   #   Failed test 'subprocess died'
>   #   at foo line 10.
>   #  got: 0
>   # expected: anything else
>   1..1
>   not ok 1 - test
>   # Failed test 'test'
>   # at foo line 17.
>   1..1
>   # Looks like you failed 1 test of 1.
>
> In the forked code, the die causes the subtest to end in failure *in the
> fork*
> meaning we get a repeat result for test 1: one from the child, one from the
> parent.  Also, the child is now exiting zero instead of nonzero, despite
> the
> fact that it threw an exception.
>
> It gets worse [for me]!  Above, I had a cmp_ok on $? that failed, so I had
> duplicate *not ok* results for test 1.  If I replace that cmp_ok with a
> pass, I
> get duplicate *conflicting* results for test 1... and then the main process
> terminates zero.  This means that the test seems to pass if you look at
> its $?,
> but the harness sees it as a failure because its total output does include
> failures (and non-increasing test numbers).
>
> Adding Test2::IPC does not help.  The issue is not synchronising test
> counters,
> or the like.  It's that I don't want the subprocess's exit to cause a
> subtest
> exit in the parent process.  I think that's right: the only process that
> should
> turn exceptions into subtest fails is the process that created the subtest.
>
> a) am I wrong?
> b) advice on how to procede?
>
> --
> rjbs
>

Re: test/subtest flow control with exceptions

[Chad Granum]

I don't have much comment on the functionality you want, seems reasonable
enough...

I do have implementation commentary however:

 * You should not be obtaining a context inside your subtest (specifically
line 18
https://github.com/rjbs/Test-Abortable/blob/master/lib/Test/Abortable.pm#L18).
Obtaining that context means that tests run inside your eval are likely to
report errors to the wrong files+lines. If you need a context that is
within the subtest you should obtain it after your eval.

 *
https://github.com/rjbs/Test-Abortable/blob/master/lib/Test/Abortable.pm#L30
 this should probably be $ctx->throw() which is essentially a die, but it
"aborts" the context so that it is released properly (not the die you use
prevents context->release from being called). Though on second thought,
throw() will append a file+line number to your exception, so you should
probably just add a $ctx->release right before that die. (and on further
reading your second sub asks if release should be done, the answer is yes.

-Chad







On Tue, Nov 29, 2016 at 5:52 PM, Ricardo Signes 
wrote:

> Often, I have a test like this:
>
>   subtest "do things with an api" => sub {
> my $result = $api_client->do_first_thing;
>
> is(
>   $result->documents->first->title,
>   "The Best Thing",
> );
>
> ...
>   };
>
> Sometimes, the result comes back with zero documents.  ->first throws an
> exception and then my whole test program comes crashing down and it's
> miserable.  For a while, I've been meaning to make it possible for some
> exceptions to be recognized by my test programs as instructions to emit a
> failure, stop this subtest, and move on.
>
> It's important to note that I'm talking, in the code above, about an
> exception
> that would be thrown by ($result->documents) when ->first is called on it.
> This kind of flow control eliminates needing to write:
>
>   my $result = $api_client->do_first_thing;
>   my $docs   = $result->documents;
>   fail("no docs"), return unless $docs->has_entries;
>   my $first  = $docs->first;
>   fail("no title"), return unless $first->has_title;
>
>   is(...);
>
> In my case, I'm working with an API client that's specifically designed to
> be
> used for testing, so this kind of loose coupling between thrown exceptions
> and
> the test code is a good fit.  Not every exception should be caught this
> way.
> Truly unexpected ones should still die.
>
> So, I've written something to do this, and I'm sharing it here before going
> further with it.  In my code, if an exception is meant to be caught and
> used as
> a local abort instruction, it has a method called as_test_abort_events.
> This
> method returns a reference to an array of Test2 event descriptions.  For
> example, maybe:
>
>   sub as_test_abort_events {
> return [
>   [ Ok   => (pass => 0, name => "no documents, but ->first called") ],
>   [ Diag => (message => "collection state: ") ],
> ];
>   }
>
> This method is easy to add to any exception you want, and you don't need to
> change your exception class hierarchy in any way.
>
> Next, you need something to run the tests and look for these exceptions
> being
> thrown.  I have written a library for this, called Test::Abortable.
>
>   https://github.com/rjbs/Test-Abortable
>
> Test::Abortable provides two subroutines: subtest and testeval.  subtest
> acts
> just like Test::More's subtest, but catches abort exceptions, emits their
> events, and returns normally.  (I've also updated my library
> Test::Routine, in
> a branch, to behave this way, as I use it in place of subtest for many
> things.)
>
> testeval acts like eval, but only catches abort exceptions.
>
>   ok(1);
>   testeval {
> ok(2);
> this_throws_an_abort;
> ok(3);
>   };
>   ok(4);
>
> This ends up emitting ok 1, ok 2, whatever the abort wants, and ok 4.
> testeval
> returns the return value of the code block if it succeeds.  If it fails
> due to
> abort, it returns false, emits the abort events, and puts the abort in
> $@.  If
> it fails because of any other exception, the exception is re-thrown.
>
> Let me know if you have any thoughts before I begin using this in anger.
> :-)
>
> --
> rjbs
>

Need feedback on an Importer interface design

[Chad Granum]

This question pertains to a new feature I have been working on for
Importer: https://metacpan.org/release/EXODIST/Importer-0.021-TRIAL

The trial release above has some known bugs, I have fixed a few, but have
not put them on github/cpan yet, be aware of that before trying it out.


I have been working on a feature called "pins". Pins are like an enhanced
form of tag. Basically pins are alternative sets of exports. The reason for
doing this is to provide a way to make backwords incompatible changes to
exports without breaking anything.

Silly Example:

package Foo;

our @EXPORT = qw/foo/;

sub foo {
my ($thing1, $thing2) = @_;
...
}


Now, say it is determined that foo() taking 2 arguments is really really
bad, so we want to make foo() only take 1 argument, and die if it gets a
second. This will break any consumers that use foo() with 2 arguments.

One option would be to keep foo() how it is, and create a new sub like
foo2(). And maybe give foo() deprecation warnings. But sometimes making a
new sub is not viable, specially if you force everyone to always use the
old name with '2' appended.

Another option would be to make foo() accept both forms, and warn that the
2 arg form will go away in a future release, though in practice it never
will, and if it did people who take too long to upgrade will miss the
deprecation window and it will just break when they upgrade.

Another option is pins. With pins you specify a default export sets, and
pinned export sets:

package Foo;

our %EXPORT_ANON = (
foo => \_foo,
);
our %EXPORT_PINS = (
root_name => 'v1', # Make default/no-pin be named 'v1'
'v2' => {
inherit => 'v1',
export_anon => { foo => \_foo }
}
);

sub legacy_foo { ... }
sub new_foo { ... }

Now what this does for consumers:

use Foo qw/foo/; # Get the legacy (don't break existing consumers
use Foo qw/+v2 foo/; # Get 'foo' from the v2 pin

Basically if you do not specify a pin it will do what it has always done,
nothing breaks. If you prefix exports with '+v2' the symbols listed next
come from the 'v2' pin.

Other "features" of pins:
 * Each pin has a complete export menu, default exports, optional exports,
anon exports, etc.
 * A tag is automatically added for each pin, so you can use ':v2' to get
all the default exports from the 'v2' pin.

There are a couple options for consumers, for instance these are identical:

use Importer 'Foo' => ('+v1' => [qw/a b/], '+v2' => [qw/c d/]);
use Importer 'Foo' => qw/+v1 ... +v2 .../;

The main difference is the first uses arrayrefs to make it more clear that
some symbols are from some pins, other symbols are from other pins.

Anyway, I have this mostly implemented, and I do have a need for it. What I
am looking for is feedback about what sucks from this, what is good from
this, etc. I would rather have the feedback before a release as opposed to
after when it might be harder to change things.

Thanks!

Re: Test2::Tools::Compare is vs. like

[Chad Granum]

The hash/field/etc builder system is always optional. You can always mix
them, it is perfectly fine to use the builders for both 'is' and 'like',
though for the builders it really does not matter which of the 2 you use
since strict/relaxed only applies to conversions of
hashrefs/arrays/scalars,  checks you build using the builders don't get
converted (though embedded hashes and arrays will).

is(
$foo,
{ # This hash is converted to checks using the strict conversion
foo => hash { # Not converted
# 'strict' conversion to string check
field a => 'xxx';

# This hash is converted using strict (cause we are inside an
is())
field b => { foo => 'bar' };

# This being here makes the foo => hash { ... } check strict. If
# end() was not specified here it would be a relaxed check,
is/like
# do not control/alter it.
end();
}
},
"description"
);

Here is a sub example for you:

like(
{foo => 'foo' },
{foo => sub { $_ eq 'foo' ? 1 : 0 } },
"Useless and trivial example of using a sub check in like"
);



On Wed, Jul 27, 2016 at 8:34 AM, Andy Lester <a...@petdance.com> wrote:

>
> On Jul 27, 2016, at 10:13 AM, Chad Granum <exodi...@gmail.com> wrote:
>
> Specifically "This will ignore hash keys or array indexes that you do not
> actually specify in your $expect structure." directly documents the
> behavior.
>
>
> Right.  That is a fact that is clearly spelled out.  I think it would be
> helpful to have something that is higher level, that explains when you use
> which, and examples for each.
>
> For instance, it might be something like (if my understanding is correct).
>
> my $employee = get_employee();
> my $expected_employee = { name => ‘Bob’, dept => ‘IT’ };
>
> # If you want to check the API, and ensure that get_employee() returns
> two and only two fields:
> is( get_employee(), $expected_employee );
>
> # If you want to check that you got the right record, but don’t care
> if it comes back with, say, a phone_number field:
> like( get_employee(), $expected_employee );
>
> Also, when do you have to use the hash/field construction system?
>
> is( $employee, { name => 'Bob', dept => 'IT' } );
> like( $employee, { name => 'Bob', dept => 'IT' } );
> is( $employee, hash {
> field name => 'Bob';
> field dept => 'IT';
> }
> );
>
> When is it appropriate to use each of these?  Is it an error to mix like()
> and hash()/field()?
>
> An example of calling like() on coderefs ("The same is true for coderefs,
> the value is passed in as the first argument (and in $_) and the sub
> should return a boolean value.”) would be good, too.
>
> I’d be glad to write the docs if I knew the answers to the questions and
> the zen of what to use when.
>
> As a newbie to Test2, I’d really like to start using it as much as
> possible, but I’m also afraid of screwing up existing tests because I use a
> new tool incorrectly.
>
> Andy
>
>
> --
> Andy Lester => www.petdance.com
>
>

Re: Test2::Tools::Compare is vs. like

[Chad Granum]

I thought I had documented the differences pretty well. If you look here
https://metacpan.org/pod/Test2::Tools::Compare#COMPARISON-TOOLS and read
both the 'is()' and 'like()' sections it makes it clear.

is:

> his is the strict checker. The strict checker requires a perfect match
> between $got and $expect. All hash fields must be specified, all array
> items must be present, etc. All non-scalar/hash/array/regex references must
> be identical (same memory address). Scalar, hash and array references will
> be traversed and compared. Regex references will be compared to see if they
> have the same pattern.
>

like:

> This is the relaxed checker. This will ignore hash keys or array indexes
> that you do not actually specify in your $expect structure. In addition
> regex and sub references will be used as validators. If you provide a regex
> using qr/.../, the regex itself will be used to validate the corresponding
> value in the $got structure. The same is true for coderefs, the value is
> passed in as the first argument (and in $_) and the sub should return a
> boolean value. In this tool regexes will stringify the thing they are
> checking.
>

Specifically "This will ignore hash keys or array indexes that you do not
actually specify in your $expect structure." directly documents the
behavior.


That said I have no opposition to making the docs more clear, and am open
to suggestions on how to reword or reorganize it.

-Chad

On Wed, Jul 27, 2016 at 8:03 AM, Andy Lester  wrote:

> I was going to mail this to Chad directly, but I think it’s worth airing
> publicly.
>
> As a newcomer to Test2, it was never clear to me until just now when to
> use is() or like() for deep structures.  Given this code:
>
> my $errors = do_something();
> is( @{$errors}, 0. ‘No errors back from do_something()’ ); # old way
>
> And the new way to check would be:
>
> is( $errors, [], ‘No errors back from do_something()’ );
>
> It would be very easy to use this instead:
>
> like( $errors, [], ‘No errors back from do_something()’ );
>
> And it looks like like() works just fine, but really it will pass even if
> $errors has something in it.
>
> is( [], [] ); # Passes
> like( [‘foo’], [] ); # passes but you wouldn’t expect it to.
>
> The docs say "This is the strict checker” and “This is the relaxed
> checker” for each of them, respectively, but I think it would be worth
> having something in the docs that explains the differences between the two.
>
> Anyone else have troubles with these two functions?  Or other gotchas
> where new features aren’t what people switching from Test::More might
> expect?
>
> Andy
>
> --
> Andy Lester => www.petdance.com
>
>

Re: Writing our own modules in Test2

[Chad Granum]

The pod for Test2.pm explains the namespaces. They are intended for all new
tools/plugins/events/etc. Test2::Xxx should be for extentions to the
framework. Test2::Tools::* and test2::Plugins etc are open to anyone.
On Jun 24, 2016 7:39 AM, "Andy Lester" <a...@petdance.com> wrote:

>
> On Jun 24, 2016, at 12:46 AM, Chad Granum <exodi...@gmail.com> wrote:
>
> Is the intent that when people will create them as
> Test2::Tools::Whatever?  Sort of like Perl::Critic::Policy::* is done?  Or
> are we still staying as Test::Whatever?
>
>
> What about naming?  Test2::Tools::Whatever?  Or do we see the Test2::Tools
> namespace being only for “official” tools?
>
> I see three options for third parties:
>
> * Test2::Tools::Whatever
> * Test2::Whatever
> * Test::Whatever
>
> My ultimate goal here is to create a batch of convenience test methods and
> also have them stand as an example of a standalone third party module.
>
>
> --
> Andy Lester => www.petdance.com
>
>

Re: Writing our own modules in Test2

[Chad Granum]

Right now the Test2::API docs are probably all that is done. But my Test2
manual grant covers the document you request as one of the 2 primary goals.
I have plans for it, and will be getting to it just as soon as I settle
back in from YAPC.
On Jun 23, 2016 7:52 PM, "Andy Lester"  wrote:

Is there a doc somewhere that explains how to write one's own test module
atop Test2?  I haven't found it if there is.

Is the intent that when people will create them as Test2::Tools::Whatever?
Sort of like Perl::Critic::Policy::* is done?  Or are we still staying as
Test::Whatever?

Do we have an FAQ started for things like this?  If not, I assume it would
be good to start one, and if so, then where should I start it?

--
Andy Lester => www.petdance.com

Re: Test2/Test::Builder release plan

[Chad Granum]

>
>
> I think 1 is a good idea, but I have some reservations about the 2 (and
> thus 4). Is it really advantageous to switch over everyone to Test2 today?
>
> I think Test2 has major benefits for some people (it makes new things
> possible), but it also has major disadvantages for others (it breaks
> stuff); both have unknown upper bounds. And to be honest, for the vast
> majority I don't feel like it will matter; they don't need (much) more than
> Test::More.
>
> Wouldn't it make more sense to make this opt-in?
>
> Leon
>
>
The main benefits of switch as opposed to opt-in are these:

 * Only maintaining one system. Yes we still need to maintain Test::Builder
and Test2, but when combined it reduces the cognitive overhead, and the
disconnect between the 2.
 * The code to switch includes bugfixes that cannot be easily/sanely
backported to old test builder
- Threads + Subtests
- Forking + Subtests
- False pass if parent finishes before child thread/process where child
then has a failure
- Probably more
 * People will not have to be worried about something downstream switching
and thus forcing them to switch unknowingly (cause the switch happens once,
for everyone)

The problems of making it opt-in are the same problems you always get when
you maintain 2 separate but similar things. Things become desynchronized
between them. People have to write their stuff to support both, or simply
make their code die with a message telling you not to use one or the other.
If we do not combine these then we put the burden of supporting both on
everyone else. If however the next Test::Builder used Test2 then the burden
is on me and any other Test2/Test::Builder maintainer. Yes there is still
the toolchain burden of making sure stuff works on new and old
Test::Builder, but toolchain is already its own beast.


I think Test2 has major benefits for some people (it makes new things
> possible), but it also has major disadvantages for others (it breaks
> stuff); both have unknown upper bounds. And to be honest, for the vast
> majority I don't feel like it will matter; they don't need (much) more than
> Test::More.


The main disadvantage is that it "breaks stuff". I do not want to
trivialize this, it is a huge concern. And you are correct, we do not know
the upper bound. What we do know though is that cpan shows us. Currently
the breakage on cpan is very small, limited to only a handful of modules,
many of which already have pending patches, or people willing to pick them
up. And most, if not all of what breaks is people bypassing Test::Builders
public API's and mucking about directly with internals. Even in these cases
hoops have been jumped though to support as many of these bad practices as
technically possible.

I do not want to dismiss or trivialize the disadvantages, I want to be
clear on that. However I consider the advantages to have significantly more
weight here. I think the burden on cpan of supporting a split system here
is a much higher risk. If the author of Test::Moose for instance decides to
switch to Test2, then any test that consumes it switches automatically. If
there is a conflict in any of the used tools then people have breakage, and
it is not as predictable. If we switch all at once though, then a module
author deciding to switch simply needs to bump up the minimum Test::Builder
version required, anything that works on that higher version *should* be
set.

-Chad

Re: Test2/Test::Builder release plan

[Chad Granum]

I am also happy to help out with information if you get hung up on anything.

On Sun, Apr 3, 2016 at 9:09 PM, Randy Stauner  wrote:

> Thanks.  Any help is appreciated.
> Here are some relevant urls:
>
> https://github.com/rwstauner/test-aggregate/issues/2
> https://rt.cpan.org/Ticket/Display.html?id=100035
> https://metacpan.org/pod/distribution/Test2/lib/Test2/Transition.pod
>
> On Sat, Mar 26, 2016 at 1:44 AM Shlomi Fish 
> wrote:
>
>> Hi all,
>>
>> On Sat, 26 Mar 2016 02:57:38 +
>> Randy Stauner  wrote:
>>
>> > As a maintainer of one of the problem modules (Test::Aggregate) i should
>> > have something to say, but I haven't been able to spend more than an
>> hour
>> > with Perl in the last year so i don't know when I'll be able to work on
>> > making it work with the changes.  I see no reason to hold up progress on
>> > this any longer, so "sounds good" to me.
>> >
>>
>> I may be willing to do some work on Test-Aggregate for that. Otherwise,
>> my use
>> of Test::More and Test::Builder is probably contained only to the very
>> high-level API , so I don't expect anything major to break, so "sounds
>> good" to
>> me as well.
>>
>> Regards,
>>
>> Shlomi Fish
>>
>> --
>> -
>> Shlomi Fish   http://www.shlomifish.org/
>> List of Portability Libraries - http://shlom.in/port-libs
>>
>> The C Preprocessor - There’s not supposed to be a way to do it.
>> — http://www.shlomifish.org/humour/ways_to_do_it.html
>>
>> Please reply to list if it's a mailing list post - http://shlom.in/reply
>> .
>>
>

Test2/Test::Builder release plan

[Chad Granum]

RJBS and I have spoken, and feel it is time to set a release date for
Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a
good time. The plan is to release Test2 and the new Test::Builder as stable
either at the end of the first day, or the start of the second day (so the
21st or 22nd of april). This gives a full day for people to grab me in
person to talk about it, and address any issues. It also gives 2 full days
after the release where my attention can be fully devoted if any issues are
discovered post-release.

I expect little if any changes to occur in the code between now and then.
Possibly some small bug fixes, documentation updates, etc. nothing big. I
will continue to listen to any feedback that is provided, and take any
necessary action. In the meantime RJBS is going to be pinging stakeholders
from the punch-list (
https://github.com/Test-More/test-more/wiki/Test-Builder-v1.3-Punchlist) to
make sure all requirements have been met.

What exactly is going stable?

* Test2 (experimental notices will be removed)

* Test::Builder that uses Test2 under the hood (as seen here:
https://metacpan.org/release/EXODIST/Test-Simple-1.302013_014)

* Test2-Suite (experimental notices will be removed)

* Final Test2/Test-Simple patch for perl blead (Test-Suite is not going
into blead)

I look forward to seeing you all in Rugby!

-Chad

Re: Last call for review of Test-Builder using Test2 (Formerly Test-Stream)

[Chad Granum]

*bump*

This thread has produced very little chatter. Bumping the thread again
after talking to rjbs. Next week he and I are going to talk about next
steps. (Please do not read that as we will talk next week and release, that
is not intended, implied, or expected).

-Chad

Re: Last call for review of Test-Builder using Test2 (Formerly Test-Stream)

[Chad Granum]

I am certainly not going to consider 24 hours of silence a reason to stamp
a stable label on it. Rjbs and I have a status meeting every week, if
things were completely silent for 2 weeks we were going to evaluate the
situation and move on from there.

In addition we still need people from the qa hackathon in berlin to confirm
or reject the assertion that their punch list items are satisfied before
the Test::Builder component can be marked stable. If they choose to be
silent on this thread we will reach out to them directly.

My point is, things are not going to happen over night, and silence will
not be taken as a seal of approval. That said, indefinite silence will also
not be considered a blocker past a point, but no time limits have been set
either way.

-Chad
On Feb 6, 2016 2:13 AM, "Kent Fredric" <kentfred...@gmail.com> wrote:

> On 6 February 2016 at 08:14, Chad Granum <exodi...@gmail.com> wrote:
> > If there is anything in these
> > distributions (Test2 in particular) that makes you uncomfortable, you
> > need to speak now.
>
>
> Mentioning here for visibility:
>
> As with Test-Stream where the apparent silence lead to a premature
> conclusion that finalisation was appropriate, I feel interpreting the
> current lull in activity in the same way equally premature.
>
> I've seen a proposal floating around that might raise our ability to
> be confident about the feature set of Test2 before requiring its
> implementation/feature-freeze.
>
> Just the people who I talked to who implied they were going to present
> said proposal haven't yet had the tuits to do so yet.
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>

Last call for review of Test-Builder using Test2 (Formerly Test-Stream)

[Chad Granum]

On October 29th, 2015, I released Test-Stream as stable. I did this because
I felt it was ready, and because I was no longer receiving any feedback from
perl-qa asking me to change things. Since that release, the feedback picked
up substantially. It seems that declaring something done is the best way
to find out ways in which it is not actually done.

Here are the big things people wanted:

 - Split the dist into multiple dists, making the internals and tools
separate.

 - Abandon the loader system (use Test::Stream -/:/etc)

 - Loosen the tight coupling of Test::Steam to TAP

 - Make context() less magic (don't use INTERNALS::SvREFCNT)

 - Use less import() magic

 - Better namespace structuring

 - Changes to how SKIP and TODO are implemented

We decided that the best way forward was to forget about compatibility
with Test-Stream, which is still new enough that it is not seeing much use,
and make a new name with
everyone's changes.  That's Test2.

After the split there are 3 distributions:

 - Test2 (https://metacpan.org/pod/Test2) - The guts. No tools, just the
   things to make tools. This is what Test::Builder will be using.

 - Test2::Suite (https://metacpan.org/pod/Test2::Suite) - New tools as an
   alternative to Test::More and friends, built directly on Test2 instead of
   Test::Builder

 - Test2::Workflow (https://metacpan.org/pod/Test2::Workflow) - The 'spec'
   plugin and workflow extension from Test::Stream. This was big enough to
be
   a separate distribution.

Test2::Suite and Test2::Workflow are optional systems.  I think you'll
find them very useful, but they're not the key deliverable.  That's
Test2, which is meant to replace Test::Builder's guts.  Test::Builder
will be a backward compatibility layer on top of Test2.

As of the latest releases of Test2 and Test2-Suite I am considering the work
done to my specifications and intentions. Now is the time to review these
and make commentary. Once this goes stable it will become much harder, if
not impossible, to make sweeping changes. If there is anything in these
distributions (Test2 in particular) that makes you uncomfortable, you
need to speak now. I am not yet ready to say Test2-Workflow is complete.


The work to make Test::Builder use Test2 under the hood is also complete.

On CPAN:
https://metacpan.org/pod/release/EXODIST/Test-Simple-1.302013_011/lib/Test/Builder.pm

On Github: https://github.com/Test-More/test-more/tree/Test2/master

Blead Patch Ticket:
https://rt.perl.org/Public/Bug/Display.html?id=127000#txn-1385453

This work has been through several verification procedures:

 - CPAN Smoking by Andreas König

 - My own testing against CPAN distributions

 - Blead patches I have written (though to date nobody has merged it in)

 - A comparison of verbose testing output on blead with and without my
   patch https://github.com/exodist/blead_stream_diff

Note: The preferred form of feedback is tickets on the relevant github
projects

-Chad

Re: new Stream Test::Simple question, XS requirement

[Chad Granum]

For now I am going to add the minimum necessary Scalar::Util version to the
requirements list in Makefile.PL. This should meet the toolchain
requirement of supporting back to 5.8.1 as Scalar::Util is on cpan for
install in perl versions where it is too old. It also sounds like this is
not a blocker for putting new Test-Simple into core.

As for people on perls older than 5.8.5 that cannot update Scalar::Util due
to XS restrictions, or people who use newer perls but cannot load
Scalar::Util, I suspect that in practice it is exceedingly rare that anyone
in this position would want to update Test-Simple, let alone need to. For
now I am not going to put effort into making Test-Simple work without
Scalar::Util. If anybody comes to me and tells me they are in this
position, and asks for my help, I would be happy to work on it.

-Chad

On Sun, Apr 26, 2015 at 5:40 AM, Ricardo Signes perl...@rjbs.manxome.org
wrote:

 * bulk88 bul...@hotmail.com [2015-04-25T23:56:23]
  Because of the rjbs post that supposedly (someone else should confirm
 this)
  minitest does not use Test::*, new Test::Simple can use all the XS it
 wants.

 Re-confirmation welcome!  For the record: My first check was scanning all
 the
 tests run by the minitest make target for 'use Test'.  Then I ran minitest
 with
 a dtrace probe for all files opened.  Only two files matching /Test/ were
 opened:

   ~$ grep Test dtrace.log | sort | uniq
   0151   open:entry miniperl ../TestInit.pm
   1151   open:entry miniperl ../TestInit.pm
   2151   open:entry miniperl ../TestInit.pm
   3151   open:entry miniperl ../TestInit.pm
   3151   open:entry miniperl
 ../lib/unicore/TestProp.pl

 --
 rjbs

Re: new Stream Test::Simple question, XS requirement

[Chad Granum]

I have no objections to having OPTIONAL XS available to speed things up for
people who want it. However I will not accept making XS a requirement. I
thought that since Scalar::Util::weaken was in core that there would be no
issues using it in a core module. If using weaken makes Test-Simple
non-corable, then I will use a slightly alternate design. But I will wait
for rjbs to weigh in on if Scalar::Util::weaken will block Test-Simple from
core.

-Chad

On Sat, Apr 25, 2015 at 2:57 PM, bulk88 bul...@hotmail.com wrote:

 Since Test::Stream::Context's core design uses weaken() everywhere, that
 means new Test::Simple always requires XS building (for Scalar::Util),
 which means it will never run on miniperl, and hence, new Test::Simple will
 never be in Perl core, is my understanding correct?

 I am asking this since if new Test::Simple is not PP clean and never will
 be, there are couple places I would like to throw XS at (the accessors in
 Test::Stream::HashBase::Meta in particular).

Re: new Stream Test::Simple question, XS requirement

[Chad Granum]

I am not sure it is entirely my decision. If it is entirely my decision
than this is it:
Must have a working scalar::util::weaken to use the new Test::Simple. The
Test-Simple dist itself will not require a c compiler to install, as in no
xs is included in the dist. A Test-Simple-XS dist may be created if desired
that will be used by Test-Simple if it is installed, but it will not be a
requirement. Up to rjbs and p5p as to of the xs components will  be part of
core.

However I want to know how the rest of perl-qa feels about this first. If
people are not bothered by using scalar::util then we have no problem. If
they are bothered by scalar::util being used then we need to look at
options.

Does anyone have a strong opinion about Test-Simple needing scalar::util?
On Apr 25, 2015 8:57 PM, bulk88 bul...@hotmail.com wrote:

 Chad Granum wrote:

 I have no objections to having OPTIONAL XS available to speed things up
 for people who want it. However I will not accept making XS a requirement.
 I thought that since Scalar::Util::weaken was in core that there would be
 no issues using it in a core module.


 Core includes XS modules. You relied on an XS module, see below.

  If using weaken makes Test-Simple non-corable, then I will use a slightly
 alternate design.


 Current new Test::Simple is slightly slower than legacy, will your
 non-weaken solution make new Test::Simple twice as slow as legacy? Because
 of the rjbs post that supposedly (someone else should confirm this)
 minitest does not use Test::*, new Test::Simple can use all the XS it
 wants. Maybe you want to change the design rule and say XS is mandatory to
 run new Test::More, but also remember, legacy Test::Simple doesn't require
 XS. There are 2 levels of requires XS, 1 is to say you must have a
 working C compiler to install new Test::Simple, the other level is to say,
 at some point in the past you or your predecessor must have had access to a
 C compiler to build the core XS modules. If your platform's perl doesn't
 have DynaLoader, or if your OS vendor/IT dept decided to only distribute
 XS-free core modules, then sorry, new Test::Simple is not supported on your
 system (must have working Scalar::Util).

 To prove new Test::Simple requires XS, I ran.

 -
 C:\perl521\srcnewb4optminiperl -IC:\sources\testmorenew\lib -Ilib
 -MTest::More
 -e0
 Can't load module List::Util, dynamic loading not available in this perl.
   (You may need to build a new perl executable which either supports
   dynamic loading or has the List::Util module statically linked into it.)
  at lib/Scalar/Util.pm line 11.
 Compilation failed in require at lib/Scalar/Util.pm line 11.
 Compilation failed in require at
 C:\sources\testmorenew\lib/Test/Stream/Util.pm line 5.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/Stream/Util.pm line 5.
 Compilation failed in require at C:\sources\testmorenew\lib/Test/Stream.pm
 line 9.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/Stream.pm line 9.
 Compilation failed in require at C:\sources\testmorenew\lib/Test/More.pm
 line 10.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/More.pm line 10.
 Compilation failed in require.
 BEGIN failed--compilation aborted.


 C:\perl521\srcnewb4opt
 -

 Legacy doesn't requre XS

 -
 C:\perl521\srcnewb4optminiperl -Ilib -MTest::More -e0

 C:\perl521\srcnewb4opt
 -

 So what is your (exodist) design rule, atleast for now, on XS and new
 Test::Simple?

Re: new Stream Test::Simple question, XS requirement

[Chad Granum]

Just to also be clear. My alternate implementation would be a fallback. If
scalar::util works it uses it, if not it falls back to a slightly different
system. The switch would happen when Context.pm is loaded. So even if the
fallback is slightly slower, few if any systems would ever experience it.
The fallback I have in mind also maintains the exact same interface, so it
would be seamless to users, and does not deviate from the current context
usage in any way.
On Apr 25, 2015 9:15 PM, Chad Granum exodi...@gmail.com wrote:

 I am not sure it is entirely my decision. If it is entirely my decision
 than this is it:
 Must have a working scalar::util::weaken to use the new Test::Simple. The
 Test-Simple dist itself will not require a c compiler to install, as in no
 xs is included in the dist. A Test-Simple-XS dist may be created if desired
 that will be used by Test-Simple if it is installed, but it will not be a
 requirement. Up to rjbs and p5p as to of the xs components will  be part of
 core.

 However I want to know how the rest of perl-qa feels about this first. If
 people are not bothered by using scalar::util then we have no problem. If
 they are bothered by scalar::util being used then we need to look at
 options.

 Does anyone have a strong opinion about Test-Simple needing scalar::util?
 On Apr 25, 2015 8:57 PM, bulk88 bul...@hotmail.com wrote:

 Chad Granum wrote:

 I have no objections to having OPTIONAL XS available to speed things up
 for people who want it. However I will not accept making XS a requirement.
 I thought that since Scalar::Util::weaken was in core that there would be
 no issues using it in a core module.


 Core includes XS modules. You relied on an XS module, see below.

  If using weaken makes Test-Simple non-corable, then I will use a
 slightly alternate design.


 Current new Test::Simple is slightly slower than legacy, will your
 non-weaken solution make new Test::Simple twice as slow as legacy? Because
 of the rjbs post that supposedly (someone else should confirm this)
 minitest does not use Test::*, new Test::Simple can use all the XS it
 wants. Maybe you want to change the design rule and say XS is mandatory to
 run new Test::More, but also remember, legacy Test::Simple doesn't require
 XS. There are 2 levels of requires XS, 1 is to say you must have a
 working C compiler to install new Test::Simple, the other level is to say,
 at some point in the past you or your predecessor must have had access to a
 C compiler to build the core XS modules. If your platform's perl doesn't
 have DynaLoader, or if your OS vendor/IT dept decided to only distribute
 XS-free core modules, then sorry, new Test::Simple is not supported on your
 system (must have working Scalar::Util).

 To prove new Test::Simple requires XS, I ran.

 -
 C:\perl521\srcnewb4optminiperl -IC:\sources\testmorenew\lib -Ilib
 -MTest::More
 -e0
 Can't load module List::Util, dynamic loading not available in this perl.
   (You may need to build a new perl executable which either supports
   dynamic loading or has the List::Util module statically linked into it.)
  at lib/Scalar/Util.pm line 11.
 Compilation failed in require at lib/Scalar/Util.pm line 11.
 Compilation failed in require at
 C:\sources\testmorenew\lib/Test/Stream/Util.pm line 5.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/Stream/Util.pm line 5.
 Compilation failed in require at
 C:\sources\testmorenew\lib/Test/Stream.pm line 9.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/Stream.pm line 9.
 Compilation failed in require at C:\sources\testmorenew\lib/Test/More.pm
 line 10.
 BEGIN failed--compilation aborted at
 C:\sources\testmorenew\lib/Test/More.pm line 10.
 Compilation failed in require.
 BEGIN failed--compilation aborted.


 C:\perl521\srcnewb4opt
 -

 Legacy doesn't requre XS

 -
 C:\perl521\srcnewb4optminiperl -Ilib -MTest::More -e0

 C:\perl521\srcnewb4opt
 -

 So what is your (exodist) design rule, atleast for now, on XS and new
 Test::Simple?

Re: Communicating between processes in test suite run

[Chad Granum]

Can you start the server and get the port in the parent process, then fork
and run the tests from the child?

On Thu, Apr 23, 2015 at 11:21 AM, Cosimo Streppone cos...@opera.com wrote:

 On 23. april 2015 19:02, Tim Bunce wrote:

  On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
 
  When the fork + exec'd daemon chooses a random port, I need to be able
  to know which port it has bound itself to, and here lies the problem.
 
  Perhaps dodge the problem by not picking a random port. Have the parent
  process look for free ports itself in some obscure part of the range.
  Then pass that port number to the daemon. There's a very small race
  hazard here but that seems quite acceptable under the circumstances.
  Especially as you'll know you've hit it because the statsd daemon will
 die.

 Thanks Tim, I can certainly experiment with this idea.
 My hunch is that port clashes will still happen, but that
 needs to be verified.

  Basically I set an ENV variable such as $ENV{STATSD_PORT_FILE} with a
  temporary random file name.
 
  In the daemon startup code, if $ENV{HARNESS_ACTIVE} and
  $ENV{STATSD_PORT_FILE} are both there (since the daemon is spawned by
  the *.t script), then the port number is saved into the file name
  indicated by $ENV{STATSD_PORT_FILE}.
 
  How is the port number is saved into the file when you don't know
  which port it has bound itself to?

 The daemon starts and binds using port 0. Still within the daemon code,
 I can then query for the used port, through regular socket calls.
 After that, I check for HARNESS_ACTIVE and STATSD_PORT_FILE
 and I write the port to the file indicated by STATSD_PORT_FILE.

 Of course I don't like that the statsd daemon code needs to know about
 this at all.

 Thanks,

 --
 Cosimo

Re: Communicating between processes in test suite run

[Chad Granum]

oops ignore my last message, obviously forking the server is a dumb idea.

On Thu, Apr 23, 2015 at 11:23 AM, Chad Granum exodi...@gmail.com wrote:

 Can you start the server and get the port in the parent process, then fork
 and run the tests from the child?

 On Thu, Apr 23, 2015 at 11:21 AM, Cosimo Streppone cos...@opera.com
 wrote:

 On 23. april 2015 19:02, Tim Bunce wrote:

  On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
 
  When the fork + exec'd daemon chooses a random port, I need to be able
  to know which port it has bound itself to, and here lies the problem.
 
  Perhaps dodge the problem by not picking a random port. Have the parent
  process look for free ports itself in some obscure part of the range.
  Then pass that port number to the daemon. There's a very small race
  hazard here but that seems quite acceptable under the circumstances.
  Especially as you'll know you've hit it because the statsd daemon will
 die.

 Thanks Tim, I can certainly experiment with this idea.
 My hunch is that port clashes will still happen, but that
 needs to be verified.

  Basically I set an ENV variable such as $ENV{STATSD_PORT_FILE} with a
  temporary random file name.
 
  In the daemon startup code, if $ENV{HARNESS_ACTIVE} and
  $ENV{STATSD_PORT_FILE} are both there (since the daemon is spawned by
  the *.t script), then the port number is saved into the file name
  indicated by $ENV{STATSD_PORT_FILE}.
 
  How is the port number is saved into the file when you don't know
  which port it has bound itself to?

 The daemon starts and binds using port 0. Still within the daemon code,
 I can then query for the used port, through regular socket calls.
 After that, I check for HARNESS_ACTIVE and STATSD_PORT_FILE
 and I write the port to the file indicated by STATSD_PORT_FILE.

 Of course I don't like that the statsd daemon code needs to know about
 this at all.

 Thanks,

 --
 Cosimo

Test-Simple punchlist status

[Chad Granum]

Original note: https://gist.github.com/dagolden/2134567dc1125d20d375


   1. A single Test-Simple branch with proposed code and a corresponding
   Test-Simple dev release to CPAN (exodist)
   Branch: https://github.com/Test-More/test-more/tree/stream/master
   Release: https://metacpan.org/release/EXODIST/Test-Simple-1.301001_104
   *Status: DONE*
   2. Single document describing all known issues (exodist to write; andk
   to review)
   Here: https://github.com/Test-More/test-more/pull/571 (Failure is due to
   Changes file, please ignore)
   *Status: Under review by ANDK*
   3. Invite people to install latest dev in their daily perls for feedback
  - Write document explaining how to do so and how to roll-back (rjbs
  and exodist)
  4. Update CPAN delta smoke: compare test results for all of CPAN with
   latest stable and latest dev (andk, leont, xdg)
   *Status: Not started*
   - on Perl verisions 5.8.1, 5.20.2; both with and without threads
  - no new changes from previous list of incompatible modules doing
  unsupported things
   5. Line-by-line review of $Test::Builder::Level back compatibility
   support (ribasushi to review; xdg to vet results)
   *Status: Not Started*
   6. bleadperl delta smoke with verbose harness output with latest stable
   and latest dev; review line-by-line diff (exodist and ether)
   *Status: Patch ready, not started*
   - should be no substantive changes (outside Test-Simple tests themselves)
   7. Performance benchmarking — while specific workloads will vary,
   generally a ~15% slowdown on a typical workload is acceptable
   *Status: Bulk88 and I have achieved near parity between legacy and the
   new stuff. Bulk88 has further patches to make it even faster than legacy,
   but they are pending. Ether has not yet verified the results.*
   - Add patches to existing bechmarking tools in Test-Simple repo (ether
  and bulk88)
  - Run benchmarks on at least Linux (exodist) and Windows

(PQAH) Doc to read before Test::More discussion

[Chad Granum]

https://github.com/Test-More/test-more/blob/stream/coexist/lib/Test/Stream/Design.pod

I was talking to a couple people about this doc. There was a suggestion
that I post It here and ask that anyone interested in the Test::More
discussion tomorrow give it a quick look.

This is not a document intended to address everything people have
discussed. This document just gives a high level overview of some of the
design decisions I took in my refactor.

Also it turns out there has been some confusion regarding the nature of my
work. To be clear: it was an incremental refactor of Test::Builder, not a
redesign. The main difference is approach, a redesign starts from scratch
with a new design. A refactor introduces new things to existing code. I am
not sure how much this matters, but it is out there for clarity sakes :-)

Re: Test::More, what we hope to achieve doc.

[Chad Granum]

Just cut a new release that fixes that unit test.

On Mon, Apr 13, 2015 at 2:42 AM, Kent Fredric kentfred...@gmail.com wrote:



 On 13 April 2015 at 20:21, Martin J. Evans martin.ev...@easysoft.com
 wrote:


 I'll post this on github if you prefer.

 Martin



 And done on your behalf: https://github.com/Test-More/test-more/issues/563

 --
 Kent

 *KENTNL* - https://metacpan.org/author/KENTNL

Re: Test::More, what we hope to achieve doc.

[Chad Granum]

Thanks for the feedback!

A few people have asked for a transition document like what you are asking
for, I have yet to write it, but it is on my list.

The main thing for a darkpan maintainer to do is this:

Run all your tests against the latest dev release on cpan (
https://metacpan.org/release/EXODIST/Test-Simple-1.301001_100). This can
easily be done with a local::lob if you do not want to actually install it.
If all your tests pass then there is nothing you need to do, everything
just works. If this is the case please mention it somewhere, such as on
this list. So far I have gotten only a handful of darkpan results, none of
them reporting anything broken. It would be nice if there was a public list
of darkpan results I can keep, and I may start one on github.

If something is broken it would be best to send me a bug report on github.
My goal is to break as little as possible, so if I do break something for
you I would prefer fixing it over making you change you things. The only
exceptions are when things are very crazy: Replacing the Test::Builder
singleton, or breaking encapsulation by directly accessing hash keys of the
Test::Builder object. The new stuff even goes so far as to support legacy
monkeypatching of key methods in the Test::Builder namespace.

-Chad

On Sun, Apr 12, 2015 at 2:01 PM, Buddy Burden barefootco...@gmail.com
wrote:

 Chad,

  https://docs.google.com/document/d/1RCqf5uOQx0-8kE_
 pGHqKSQr7zsJDXkblyNJoVR2mF1A/edit?usp=sharing

 Several people have asked for this, so I wrote it up.


 Excellent document.  And, since I haven't said it yet, I applaud your
 bravery for taking on this task.

 One thing I would like to see which I don't believe I've seen yet (or
 perhaps I just missed it) is a some advice for the DarkPAN-ers out there.
 If there were some sort of checklist that we could use to go through our
 test suites ahead of time, I for one would love to go ahead and jump on
 that.  Something like: If your test suite infrastructure does X, then you
 will need to change it to Y for the new system.  Etc. Also, the solutions
 would ideally be things that would work with both old and new, otherwise
 getting the timing right may be tricky for many folks ...


 -- Buddy

Re: Test::More, what we hope to achieve doc.

[Chad Granum]

https://github.com/Test-More/test-more/blob/stream/replace/lib/Test/Stream/Transition.pod

Initial, and very sparse transition document. If there are specific things
you want added please feel free to comment on it, or make requests :-)

On Sun, Apr 12, 2015 at 2:14 PM, Chad Granum exodi...@gmail.com wrote:

 Thanks for the feedback!

 A few people have asked for a transition document like what you are asking
 for, I have yet to write it, but it is on my list.

 The main thing for a darkpan maintainer to do is this:

 Run all your tests against the latest dev release on cpan (
 https://metacpan.org/release/EXODIST/Test-Simple-1.301001_100). This can
 easily be done with a local::lob if you do not want to actually install it.
 If all your tests pass then there is nothing you need to do, everything
 just works. If this is the case please mention it somewhere, such as on
 this list. So far I have gotten only a handful of darkpan results, none of
 them reporting anything broken. It would be nice if there was a public list
 of darkpan results I can keep, and I may start one on github.

 If something is broken it would be best to send me a bug report on github.
 My goal is to break as little as possible, so if I do break something for
 you I would prefer fixing it over making you change you things. The only
 exceptions are when things are very crazy: Replacing the Test::Builder
 singleton, or breaking encapsulation by directly accessing hash keys of the
 Test::Builder object. The new stuff even goes so far as to support legacy
 monkeypatching of key methods in the Test::Builder namespace.

 -Chad

 On Sun, Apr 12, 2015 at 2:01 PM, Buddy Burden barefootco...@gmail.com
 wrote:

 Chad,

  https://docs.google.com/document/d/1RCqf5uOQx0-8kE_
 pGHqKSQr7zsJDXkblyNJoVR2mF1A/edit?usp=sharing

 Several people have asked for this, so I wrote it up.


 Excellent document.  And, since I haven't said it yet, I applaud your
 bravery for taking on this task.

 One thing I would like to see which I don't believe I've seen yet (or
 perhaps I just missed it) is a some advice for the DarkPAN-ers out there.
 If there were some sort of checklist that we could use to go through our
 test suites ahead of time, I for one would love to go ahead and jump on
 that.  Something like: If your test suite infrastructure does X, then you
 will need to change it to Y for the new system.  Etc. Also, the solutions
 would ideally be things that would work with both old and new, otherwise
 getting the timing right may be tricky for many folks ...


 -- Buddy

Test::More, what we hope to achieve doc.

[Chad Granum]

https://docs.google.com/document/d/1RCqf5uOQx0-8kE_pGHqKSQr7zsJDXkblyNJoVR2mF1A/edit?usp=sharing

Several people have asked for this, so I wrote it up.

-Chad

Re: Test-Simple schedule change, Was: Test-Simple changes to go stable Saturday Jan 10'th

[Chad Granum]

http://blogs.perl.org/users/chad_exodist_granum/2015/01/test-simple-updated-release-plan.html

Now planning to go stable 2015-03-19, to sync up a bit more with the
blead-release cycle.

On Sun, Jan 4, 2015 at 8:30 AM, Chad Granum exodi...@gmail.com wrote:

 Related blog post:
 http://blogs.perl.org/users/chad_exodist_granum/2015/01/test-simple-release-plan.html

 TL;DR: Unless someone finds something significant I will release the new
 internals for Test-Simple/More/Builder next Saturday.

 If this is a problem for you, or if you know of something broken please
 notify me, preferably with a bug on github.:
 https://github.com/Test-More/test-more/issues/

 This is probably a good time for you to run any extra tests and checks.

 Thank you,

 -Chad

Test-Simple changes to go stable Saturday Jan 10'th

[Chad Granum]

Related blog post:
http://blogs.perl.org/users/chad_exodist_granum/2015/01/test-simple-release-plan.html

TL;DR: Unless someone finds something significant I will release the new
internals for Test-Simple/More/Builder next Saturday.

If this is a problem for you, or if you know of something broken please
notify me, preferably with a bug on github.:
https://github.com/Test-More/test-more/issues/

This is probably a good time for you to run any extra tests and checks.

Thank you,

-Chad

Re: Anybody wanna adopt Test::Class, Test::Exception Test::Block

[Chad Granum]

Adrian,

Looks like even with the handoff permission set you need to make the
handoff. Would you please alter the permissions and assign them to me?
Ribasushi will also be a co-maintainer, I can add that myself once I am
listed as the owner.

Thanks!
-Chad


On Sun, Jul 27, 2014 at 10:14 PM, Chad Granum exodi...@gmail.com wrote:

 I would be happy to take on Test::Exception.


 On Fri, Jul 25, 2014 at 6:26 AM, Adrian Howard adri...@quietstars.com
 wrote:

 Hi Karen,

 On 13 Jul 2014, at 16:56, Karen Etheridge p...@froods.org wrote:

 
  You can also reach a wider audience by granting comaint or first-come
  privileges to one of ADOPTME, HANDOFF, or NEEDHELP, which allows the
 PAUSE
  admins to grant permissions immediately when someone willing comes
 along:
 [snip]

 A belated Thanks. I’d completely forgotten about this. Everything now
 has HANDOFF as comaint.

 Cheers,

 Adrian

 --
 adri...@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com
 (CSSTWP.com the product team certification programme you can trust! ;-)

Re: Anybody wanna adopt Test::Class, Test::Exception Test::Block

[Chad Granum]

I would be happy to take on Test::Exception.


On Fri, Jul 25, 2014 at 6:26 AM, Adrian Howard adri...@quietstars.com
wrote:

 Hi Karen,

 On 13 Jul 2014, at 16:56, Karen Etheridge p...@froods.org wrote:

 
  You can also reach a wider audience by granting comaint or first-come
  privileges to one of ADOPTME, HANDOFF, or NEEDHELP, which allows the
 PAUSE
  admins to grant permissions immediately when someone willing comes along:
 [snip]

 A belated Thanks. I’d completely forgotten about this. Everything now
 has HANDOFF as comaint.

 Cheers,

 Adrian

 --
 adri...@quietstars.com / +44 (0)7752 419080 / @adrianh / quietstars.com
 (CSSTWP.com the product team certification programme you can trust! ;-)