Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06
Michael G Schwern schrieb am 30.03.2011 um 10:37 (+1100):
> (moving this to perl-qa because we decided to retire test-users)
Yeah, I noticed only after sending the mail to the test-users list.
> > I like a nice function syntax that doesn't require a lot of
> > punctuation. However, if you add a test to your capture block in a
> > position other than at the end, you'll have to update all the array
> > indices, which is awkward.
>
> The intention is to mitigate that by making your capture blocks small,
> but I hear ya. Good point.
>
>
> > Wouldn't it therefore be better to make a closure over the results
> > that maintains the array index for you?
> >
> > my $checker = make_result_checker $history->results;
> > $checker->( {
> > is_pass => 0,
> > name=> "this is that",
> > file=> $0,
> > } );
> > $checker->( {
> > …
> > } );
>
> Took me a moment to understand that. Would this cover your need?
>
> result_like shift @$results, {
> ...
> };
That's very good! But does it mess with $history's results directly?
Or does $history->result return a shallow copy of the results?
> If you like it, could I get you to document the concern and technique
> in an EXAMPLES section?
> https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
Yes, you could. If you want me to commit directly, my github login is
milu71. Else I can send you an email.
--
Michael Ludwig
Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06
On 2011.3.31 10:00 AM, Michael Ludwig wrote:
>> Took me a moment to understand that. Would this cover your need?
>>
>> result_like shift @$results, {
>> ...
>> };
>
> That's very good! But does it mess with $history's results directly?
> Or does $history->result return a shallow copy of the results?
Right now it messes with the directly. That's ok since that history object is
allocated just for the capture() run.
>> If you like it, could I get you to document the concern and technique
>> in an EXAMPLES section?
>> https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
>
> Yes, you could. If you want me to commit directly, my github login is
> milu71. Else I can send you an email.
How a bout a fork and pull request please?
--
100. Claymore mines are not filled with yummy candy, and it is wrong
to tell new soldiers that they are.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06
[resending from correct address]
Michael G Schwern schrieb am 30.03.2011 um 10:37 (+1100):
> (moving this to perl-qa because we decided to retire test-users)
Yeah, I noticed only after sending the mail to the test-users list.
> > I like a nice function syntax that doesn't require a lot of
> > punctuation. However, if you add a test to your capture block in a
> > position other than at the end, you'll have to update all the array
> > indices, which is awkward.
>
> The intention is to mitigate that by making your capture blocks small,
> but I hear ya. Good point.
>
>
> > Wouldn't it therefore be better to make a closure over the results
> > that maintains the array index for you?
> >
> > my $checker = make_result_checker $history->results;
> > $checker->( {
> > is_pass => 0,
> > name=> "this is that",
> > file=> $0,
> > } );
> > $checker->( {
> > …
> > } );
>
> Took me a moment to understand that. Would this cover your need?
>
> result_like shift @$results, {
> ...
> };
That's very good! But does it mess with $history's results directly?
Or does $history->result return a shallow copy of the results?
> If you like it, could I get you to document the concern and technique
> in an EXAMPLES section?
> https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
Yes, you could. If you want me to commit directly, my github login is
milu71. Else I can send you an email.
--
Michael Ludwig
Re: [test-more-users] [ANNOUNCE] Test::Builder2 2.00_06
(moving this to perl-qa because we decided to retire test-users)
On 2011.3.30 6:52 AM, Michael Ludwig wrote:
> Michael G Schwern schrieb am 27.01.2011 um 12:09 (+1000):
>> use Test::More;
>> use Test::Builder2::Tester;
>>
>> my $history = capture {
>> plan tests => 2;
>> is "this", "that", "this is that";
>> ok 1, "pass";
>> };
>>
>> my $plan = $history->plan;
>> is $plan->asserts_expected, 2;
>>
>> my $results = $history->results;
>> result_like $results->[0], {
>> …
>
>> result_like $results->[1], {
>> …
>
> I like a nice function syntax that doesn't require a lot of punctuation.
> However, if you add a test to your capture block in a position other
> than at the end, you'll have to update all the array indices, which is
> awkward.
The intention is to mitigate that by making your capture blocks small, but I
hear ya. Good point.
> Wouldn't it therefore be better to make a closure over the results that
> maintains the array index for you?
>
> my $checker = make_result_checker $history->results;
> $checker->( {
> is_pass => 0,
> name=> "this is that",
> file=> $0,
> } );
> $checker->( {
> …
> } );
Took me a moment to understand that. Would this cover your need?
result_like shift @$results, {
...
};
And it's not hard wired.
If you like it, could I get you to document the concern and technique in an
EXAMPLES section?
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
--
125. Two drink limit does not mean two kinds of drinks.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
[ANNOUNCE] Test::Builder2 2.00_06
https://github.com/schwern/test-more/tree/v2.00_06
Apparently the way you make me write code is send me to a Linux conference.
This is the sixth alpha release of Test::Builder2 and it is a big one. Maybe
not in lines of code, but in concepts.
The major bits are:
The Design Is Working
-
The biggest thing bout this release is that it's all coming together.
The event design is solving old problems and neatly handling new ones. This
is an excellent indication of TB2's future flexibility.
Test::Builder2::Tester was almost trivial. Test::Builder is getting simpler
as more of its state handling and logic is pushed down into events. The
number of issues in the tracker is for the first time falling. Slightly.
Stable Is In Sight!
---
...through a telescope. But it's a ground based one!
I've gone through the issues and tagged everything blocking a stable release.
https://github.com/schwern/test-more/issues/labels/Blocking%20Stable
I've created a meta-issue listing the requirements for a stable release.
https://github.com/schwern/test-more/issues/issue/127
* There are no publicly visible bad ideas in Test::Builder2
* Test::More is using Test::Builder2 (complex use case)
o Demonstrates TB2 and TB1 working together
* DONE All the Test::Builder stuff still works
* DONE A formatter independent Test:: tester is available
* Use cases demonstrations
o DONE Die/debug on fail (result hooks)
o Test::Warn/Exception (nested, but independent, asserts)
o DONE Test::NoWarnings (event hooks)
* CPAN works
o Except the modules that do evil things to Test::Builder
+ Unless they're really important
# In which case we'll ensure they're updated for TB2
Test::Builder will work with a non TAP formatter
This was a big blocker to letting all the existing Test:: modules play with
Test::Builder2.
In previous alpha releases, Test::Builder needed to call special methods on
the TAP formatter to preserve existing features. Now a lot of that
functionality has either been moved into the History (where it belongs so
everybody has it) or TB1 makes them optional (ie. calls them in an eval).
Test::Builder delegates plan state to History
-
This was another blocker to letting existing Test:: modules play with TB2.
Test::Builder was designed as a monolith. It would track things like details
of the plan, if the plan had been set, etc. In TB2, things other than
Test::Builder might set the plan. So TB1 was being very impolite doing its
own tracking. This tracking has been moved into the History object available
to everyone as Test::Builder2::History->plan.
Test::Builder2::Tester
--
A proof of concept implementation of a Test:: module tester using
Test::Builder2. It is very small and elegant. The interface works much like
Test::Tester.
I would really really really appreciate if other people worked on this so I
don't have to.
use Test::More;
use Test::Builder2::Tester;
my $history = capture {
plan tests => 2;
is "this", "that", "this is that";
ok 1, "pass";
};
my $plan = $history->plan;
is $plan->asserts_expected, 2;
my $results = $history->results;
result_like $results->[0], {
is_pass => 0,
name=> "this is that",
file=> $0,
# Test::More doesn't do diagnostics this way yet
# diagnostics => {
# have=> "this",
# want=> "that",
# },
};
result_like $results->[1], {
is_pass => 1,
file=> $0
};
done_testing;
capture() stores everything which happens in the block in its own history
which it hands back to the user. You get all the same information which
Test::Builder does. The actual functions for testing results are currently
lame... but that's ok because you can use any Test:: module you want to test
them.
This was not planned, but just something which the event design made easy.
(If you run this, it's a bit leaky because diagnostics aren't run through the
formatter yet, but that will fix itself.)
2.00_06 Thu, 27 Jan 2011 09:58:35 +1000
Incompatible Changes
* The EventCoordinator now only has one history object.
histories() is now history(). clear_history() and add_histories()
are gone. [github 115]
* Subtest handling has been removed from the TAP formatter. The design
was wrong. It will come back later in a better form [github 120]
* Test::Builder2::Counter, History and Formatter are no longer singletons.
This is unnecessary, use the objects provided by your EventCoordinator.
[github 117]
* stream_depth() is now a method on the History object, not the TAP
formatter. This makes it available to all event watchers.
