Re: Test::Builder2::Tester, first cut
On Jan 26, 1:41 am, Michael G Schwern wrote:
> Sorry, I didn't look around at other interfaces. I was mostly like
> "OMG the test tester is so SIMPLE now with the event system! I'll
> implement it and start using it RIGHT NOW!" I haven't really thought
> it through beyond that.
>
> I'd be *very* happy to have other people drive development of
> TB2::Tester. Please, I have too much on my plate. If you tell me
> your github ID I'll give you a commit bit. You're welcome to break
> the interface so long as you refactor the stuff that uses it along
> with it.
I have pretty much stopped perl dev and have shed maintenance of a
couple of modules so I won't be stepping up to this.
> As for a TB1->TB2 transition plan, the TB2::Tester approach will work
> transparently with Test:: modules written with Test::Builder... as
> soon as I patch up Test::Builder to not be quite so in bed with the
> TAP formatter. It's the next thing on my plate.
Great,
F
> On Jan 25, 10:48 pm, Fergal Daly wrote:
>
>
>
>
>
>
>
> > Test::Tester has been doing exactly this for years
>
> >http://search.cpan.org/~fdaly/Test-Tester-0.107/
>
> > but is very much tied to the Test::Builder guts (by necessity). While
> > it supports what you have below, the vast majority of the time I just
> > used the convenience function check_test() which expects you to run
> > just a single test and combines the capture and comparison steps into
> > a single call. It also has check_tests but I hardly ever used it. E.g.
>
> > I'll happily retire Test::Tester but I would also like to find a way
> > to keep it working through the migration of Test::Builder to
> > F
>
> > 2011/1/25 Michael G Schwern :
>
> > > I'm happy to announce the first rev of Test::Builder2::Tester. It lets
> > > you
> > > test Test:: modules without doing string compares on the TAP. You can
> > > test a
> > > much wider array of detail and much simpler.
> > >https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Buil...
>
> > > Here's an example testing Test::Simple ok():
>
> > > use Test::Simple tests => 2;
> > > use Test::Builder2::Tester;
>
> > > my $history = capture {
> > > ok 2+2==5, "addition";
> > > ok 2*2==4, "multiplication";
> > > };
>
> > > my $results = $history->results;
>
> > > result_like $results->[0], {
> > > is_pass => 0,
> > > name => "addition",
> > > file => $0
> > > };
>
> > > result_like $results->[1], {
> > > is_pass => 1,
> > > name => "multiplication",
> > > file => $0
> > > };
>
> > > done_testing;
>
> > > Using Chad's idea, the code being tested is isolated from the rest of the
> > > test
> > > inside a capture() block. This returns the complete history of whatever
> > > happened inside its block. This includes every test event and result,
> > > all the
> > > same information Test::Builder2 uses itself. result_like() is a
> > > convenience
> > > function which will check only the attributes you specify and ignore the
> > > rest.
>
> > This looks remarkably similar to Test::Tester :)
>
> > Please have a look at its interface (I'm a little surprised that you
> > seem unaware of it). Almost all uses of it boiled down to a single
> > function check_test() which was a convenience function which combines
> > the 2 you have above e .g.
>
> > check_test(
> > sub {
> > is_mystyle_eq("this", "that", "not eq");
> > },
> > {
> > ok => 0, # expect this to fail
> > name => "not eq",
> > diag => "Expected: 'this'\nGot: 'that'",
> > }
> > );
>
> > which ensures that you ran 1 test in the sub, and then compares the
> > results to those you've provided. There was also a check_tests() which
> > expected an array of results and ensured you ran that many tests but
> > it was almost never used.
>
> > > This makes testing a Test:: module much more straight forward and
> > > powerful.
> > > Most importantly, it shields the Test:: module from little changes to the
> > > test
> > > output format.
>
> > > TB2::Tester is currently a rough proof of concept. result_like() doesn't
> > > produce much in the way of useful diagnostics. results_like() would
> > > likely be
> > > more convenient. It will eventually work with Test::Builder based
> > > modules,
> > > but they don't work without a TAP formatter just yet.
>
> > I would love to retire Test::Tester but it's used by Test:Deep and
> > some others (and I know it's been used privately too). At the very
> > least I'd like it to keep working when Test::Builder switches to using
> > TB2 but it looks a lot like it could become a very thin wrapper around
> > Test::Builder2::Tester which would be even better,
Re: Test::Builder2::Tester, first cut
Test::Tester has been doing exactly this for years
http://search.cpan.org/~fdaly/Test-Tester-0.107/
but is very much tied to the Test::Builder guts (by necessity). While
it supports what you have below, the vast majority of the time I just
used the convenience function check_test() which expects you to run
just a single test and combines the capture and comparison steps into
a single call. It also has check_tests but I hardly ever used it. E.g.
I'll happily retire Test::Tester but I would also like to find a way
to keep it working through the migration of Test::Builder to
F
2011/1/25 Michael G Schwern :
> I'm happy to announce the first rev of Test::Builder2::Tester. It lets you
> test Test:: modules without doing string compares on the TAP. You can test a
> much wider array of detail and much simpler.
> https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
>
> Here's an example testing Test::Simple ok():
>
> use Test::Simple tests => 2;
> use Test::Builder2::Tester;
>
> my $history = capture {
> ok 2+2==5, "addition";
> ok 2*2==4, "multiplication";
> };
>
> my $results = $history->results;
>
> result_like $results->[0], {
> is_pass => 0,
> name => "addition",
> file => $0
> };
>
> result_like $results->[1], {
> is_pass => 1,
> name => "multiplication",
> file => $0
> };
>
> done_testing;
>
> Using Chad's idea, the code being tested is isolated from the rest of the test
> inside a capture() block. This returns the complete history of whatever
> happened inside its block. This includes every test event and result, all the
> same information Test::Builder2 uses itself. result_like() is a convenience
> function which will check only the attributes you specify and ignore the rest.
This looks remarkably similar to Test::Tester :)
Please have a look at its interface (I'm a little surprised that you
seem unaware of it). Almost all uses of it boiled down to a single
function check_test() which was a convenience function which combines
the 2 you have above e .g.
check_test(
sub {
is_mystyle_eq("this", "that", "not eq");
},
{
ok => 0, # expect this to fail
name => "not eq",
diag => "Expected: 'this'\nGot: 'that'",
}
);
which ensures that you ran 1 test in the sub, and then compares the
results to those you've provided. There was also a check_tests() which
expected an array of results and ensured you ran that many tests but
it was almost never used.
> This makes testing a Test:: module much more straight forward and powerful.
> Most importantly, it shields the Test:: module from little changes to the test
> output format.
>
> TB2::Tester is currently a rough proof of concept. result_like() doesn't
> produce much in the way of useful diagnostics. results_like() would likely be
> more convenient. It will eventually work with Test::Builder based modules,
> but they don't work without a TAP formatter just yet.
I would love to retire Test::Tester but it's used by Test:Deep and
some others (and I know it's been used privately too). At the very
least I'd like it to keep working when Test::Builder switches to using
TB2 but it looks a lot like it could become a very thin wrapper around
Test::Builder2::Tester which would be even better,
F
>
> --
> You are wicked and wrong to have broken inside and peeked at the
> implementation and then relied upon it.
> -- tchrist in <31832.969261130@chthon>
>
>
Test::Builder2::Tester, first cut
I'm happy to announce the first rev of Test::Builder2::Tester. It lets you
test Test:: modules without doing string compares on the TAP. You can test a
much wider array of detail and much simpler.
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
Here's an example testing Test::Simple ok():
use Test::Simple tests => 2;
use Test::Builder2::Tester;
my $history = capture {
ok 2+2==5, "addition";
ok 2*2==4, "multiplication";
};
my $results = $history->results;
result_like $results->[0], {
is_pass => 0,
name=> "addition",
file=> $0
};
result_like $results->[1], {
is_pass => 1,
name=> "multiplication",
file=> $0
};
done_testing;
Using Chad's idea, the code being tested is isolated from the rest of the test
inside a capture() block. This returns the complete history of whatever
happened inside its block. This includes every test event and result, all the
same information Test::Builder2 uses itself. result_like() is a convenience
function which will check only the attributes you specify and ignore the rest.
This makes testing a Test:: module much more straight forward and powerful.
Most importantly, it shields the Test:: module from little changes to the test
output format.
TB2::Tester is currently a rough proof of concept. result_like() doesn't
produce much in the way of useful diagnostics. results_like() would likely be
more convenient. It will eventually work with Test::Builder based modules,
but they don't work without a TAP formatter just yet.
--
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in <31832.969261130@chthon>
