Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Thu, Jun 25, 2009 at 07:57:42AM -0400, Michael G Schwern wrote:
> Ovid wrote:
> > In any event, I'm completely mystified why anyone has a problem with
> > the "subtest $name, sub { ...}" syntax. Honestly :)
>
> So why are people so bothered by it? Is it mostly about not wanting "sub" in
> there?
I'm not sure that anyone is particularly bothered by it. As the one who
started this little sub-thread I'm certainly not. I'm just happy to
have the feature.
I just wanted to be sure that the interface I would have chosen after
about two seconds of consideration had been rejected after at least a
similar amount of deliberation. That seems to have been the case.
And yes, is was the "sub" which initially hit me when I read the
annoucement and struck me as slighly out of place.
I only really replied since I had a couple of minutes whilst waiting for
something to complete. Blame the slow server I'm developing on. The
whole thing is probably down to that butterfly in Brazil that just won't
stop flappings its wings.
--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
David E. Wheeler wrote:
> On Jun 24, 2009, at 9:59 PM, David Golden wrote:
>
>> As long as we're bike-shedding, a simplification:
>>
>> subtest {
>>plan "sanity check" => 3;
>>pass for 1 .. 3;
>> }
>>
>> Anything other than "no_plan" or "skip_all" is taken as if "tests".
>
> I thought of that and dismissed it, but seeing it in print…gets my vote!
Too bad we'll never be able to add a new keyword to plan() ever again.
Ovid wrote:
> In any event, I'm completely mystified why anyone has a problem with
> the "subtest $name, sub { ...}" syntax. Honestly :)
So why are people so bothered by it? Is it mostly about not wanting "sub" in
there?
--
Defender of Lexical Encapsulation
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Thu, Jun 25, 2009 at 5:49 AM, Ovid wrote:
> I understand where you're coming from, but different things should look
> different. SKIP and TODO are relatively similar, but subtests are
> significantly different from them.
The implementation is vastly different, but semantically, they just
provide context around a set of tests.
Though it does make me wonder how/whether subtests can be marked TODO.
(Whereas SKIP can be done through skip_all with plan). Does plan()
need a "todo/todo_all" option? Or would it be just nesting a TODO
block in the subtest?
> In any event, I'm completely mystified why anyone has a problem with the
> "subtest $name, sub { ...}" syntax. Honestly :)
I don't really have a problem with it, either, other than golf score.
Though I'd still possibly prefer something like this:
subtest "Sanity check" => sub {
plan 3; # or subplan()
pass for 1..3;
}
-- David
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
--- On Thu, 25/6/09, Josh Heumann wrote:
> From: Josh Heumann
>
> > As long as we're bike-shedding, a simplification:
> >
> > subtest {
> > plan "sanity check" => 3;
> > pass for 1 .. 3;
> > }
>
> +1
>
> I like anything that keeps it roughly in line with the
> syntax for TODO
> and SKIP blocks:
I understand where you're coming from, but different things should look
different. SKIP and TODO are relatively similar, but subtests are
significantly different from them.
In any event, I'm completely mystified why anyone has a problem with the
"subtest $name, sub { ...}" syntax. Honestly :)
But since I don't have a clue and am not particularly fussed, I'll just bow out
and let you folks have at it.
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
> As long as we're bike-shedding, a simplification:
>
> subtest {
> plan "sanity check" => 3;
> pass for 1 .. 3;
> }
+1
I like anything that keeps it roughly in line with the syntax for TODO
and SKIP blocks:
SKIP: {
skip $why, $how_many unless $have_some_feature;
ok( foo(), $test_name );
is( foo(42), 23, $test_name );
};
TODO: {
local $TODO = $why;
ok( foo(), $test_name );
is( foo(42), 23, $test_name );
};
J
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Jun 24, 2009, at 9:59 PM, David Golden wrote:
As long as we're bike-shedding, a simplification:
subtest {
plan "sanity check" => 3;
pass for 1 .. 3;
}
Anything other than "no_plan" or "skip_all" is taken as if "tests".
I thought of that and dismissed it, but seeing it in print…gets my
vote! :-)
Best,
David
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Thu, Jun 25, 2009 at 12:08 AM, David E. Wheeler wrote:
> The how about:
>
> subtest {
> plan tests => 3,
> for => 'my sanity';
> pass; pass; pass;
> }
>
As long as we're bike-shedding, a simplification:
subtest {
plan "sanity check" => 3;
pass for 1 .. 3;
}
Anything other than "no_plan" or "skip_all" is taken as if "tests".
-- David
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Jun 24, 2009, at 8:32 PM, Michael G Schwern wrote:
subtest {
name 'text';
pass;
};
That's interesting, though I don't think its worthwhile as the name
is serving
a dual purpose as mentioned above. It's not just the name of the
subtest but
also explaining what the subtest block is doing to the person
reading the
code. It serves that purpose better at the front.
The how about:
subtest {
plan tests => 3,
for => 'my sanity';
pass; pass; pass;
}
Best,
David
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
Paul Johnson wrote:
> One question though. Why
>
> subtest "text", sub {};
>
> rather than
>
> subtest {}, "text";
>
> ?
>
> The latter seems more consistent as well as removing a rather annoying bit of
> syntax. Were you worried that "text" might get lost at the end of the sub?
Not so much lost as the purpose of "text" is to describe what the big block of
test code is going to do. Putting it last defeats that purpose.
{
...some code...
}
# This is what that code above did.
Also you got the syntax wrong, which illustrates the other reason.
David Wheeler wrote:
> Even better, get rid of the two arguments:
>
> subtest {
> name 'text';
> pass;
> };
That's interesting, though I don't think its worthwhile as the name is serving
a dual purpose as mentioned above. It's not just the name of the subtest but
also explaining what the subtest block is doing to the person reading the
code. It serves that purpose better at the front.
--
39. Not allowed to ask for the day off due to religious purposes, on the
basis that the world is going to end, more than once.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Tue, Jun 23, 2009 at 04:07:55PM -0400, Michael G Schwern wrote:
> is_passing()
>
>
> As a side effect of this work, there is finally a way to tell if a test is
> currently passing. Test::Builder->is_passing(). Its really "have I failed
> yet", but if you don't think about it too hard is_passing() makes sense. The
> name is up in the air. failed_yet() is one idea which returns the number of
> tests which have failed (or violated the plan).
FYI, I'd have found a failed_yet(), and subtests, very useful recently.
The NYTProf tests run each test 8 times with various combinations of
options (set via the NYTPROF env var).
Sometimes it's hard to tell if a failure is related to certain
combinations. So I added this quick hack to NYTProf's test library:
sub count_of_failed_tests {
my @details = Test::Builder->new->details;
return scalar grep { not $_->{ok} } @details;
}
and used it to produce this kind of report:
# Test failures of test21-streval3 related to settings:
#compress: 0 => {fail 1,pass 7}, 1 => {pass 8}
# leave: 0 => {pass 8}, 1 => {fail 1,pass 7}
# savesrc: 0 => {pass 8}, 1 => {fail 1,pass 7}
# use_db_sub: 0 => {pass 8}, 1 => {fail 1,pass 7}
(In this case the issue wasn't directly related to the settings
but simply a side effect of the virtual machine being very slow
http://www.nntp.perl.org/group/perl.cpan.testers/2009/06/msg4227689.html)
So count this as a vote for $count_of_failures = $b->failed_yet();
Tim.
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
- Original Message
> From: Paul Johnson
>
> One question though. Why
>
> subtest "text", sub {};
>
> rather than
>
> subtest {}, "text";
>
> ?
>
> The latter seems more consistent as well as removing a rather annoying bit of
> syntax. Were you worried that "text" might get lost at the end of the sub?
I would prefer the 'subtest {}, "text"' syntax, but you're right, the concern
is the text getting lost at the end. It's especially bad if you have a really
long block of tests in your subtests.
In any event, it's in Schwern's hands now :)
Cheers,
Ovid
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Tech blog- http://use.perl.org/~Ovid/journal/
Twitter - http://twitter.com/OvidPerl
Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Jun 23, 2009, at 2:22 PM, Paul Johnson wrote:
One question though. Why
subtest "text", sub {};
rather than
subtest {}, "text";
?
The latter seems more consistent as well as removing a rather
annoying bit of
syntax. Were you worried that "text" might get lost at the end of
the sub?
Even better, get rid of the two arguments:
subtest {
name 'text';
pass;
};
Best,
David
Re: [ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
On Tue, Jun 23, 2009 at 04:07:55PM -0400, Michael G Schwern wrote:
> Small change log, big feature. This version adds subtest(), implemented by
> Ovid. This allows you to run a bunch of tests with their own plan.
>
> use Test::More tests => 3;
>
> pass("First test");
>
> subtest 'An example subtest' => sub {
> plan tests => 2;
>
> pass("This is a subtest");
> pass("So is this");
> };
>
> pass("Third test");
Very nice.
One question though. Why
subtest "text", sub {};
rather than
subtest {}, "text";
?
The latter seems more consistent as well as removing a rather annoying bit of
syntax. Were you worried that "text" might get lost at the end of the sub?
--
Paul Johnson - p...@pjcj.net
http://www.pjcj.net
[ANNOUNCE] Test::More/Builder 0.89_01 now with subtests
This is an alpha release of Test::More available on CPAN and from its
repository.
http://github.com/schwern/test-more/tree/v0.89_01
subtest()
-
Small change log, big feature. This version adds subtest(), implemented by
Ovid. This allows you to run a bunch of tests with their own plan.
use Test::More tests => 3;
pass("First test");
subtest 'An example subtest' => sub {
plan tests => 2;
pass("This is a subtest");
pass("So is this");
};
pass("Third test");
This would produce.
1..3
ok 1 - First test
1..2
ok 1 - This is a subtest
ok 2 - So is this
ok 2 - An example subtest
ok 3 - Third test
Current TAP parsers (Test::Harness) will ignore the indented "nested TAP", but
the result of the subtest() is itself encoded as a test ("ok 2" above) so
current TAP parsers can still see if the subtest passes or fails.
Future TAP parsers may parse nested TAP. Its not part of the standard (such
as there is) but it is also not in violation.
is_passing()
As a side effect of this work, there is finally a way to tell if a test is
currently passing. Test::Builder->is_passing(). Its really "have I failed
yet", but if you don't think about it too hard is_passing() makes sense. The
name is up in the air. failed_yet() is one idea which returns the number of
tests which have failed (or violated the plan).
0.89_01 Tue Jun 23 15:13:16 EDT 2009
New Features
* subtest() allows you to run more tests in their own plan.
(Thanks Ovid!)
* Test::Builder->is_passing() will let you check if the test is
currently passing.
Docs
* Finally added a note about the "Wide character in print" warning and
how to work around it.
--
But there's no sense crying over every mistake.
You just keep on trying till you run out of cake.
-- Jonathan Coulton, "Still Alive"
